tor-commits January 2019

tor-commits@lists.torproject.org

15 participants
2081 discussions

[obfs4/master] Clean up static analysis warnings
by yawning＠torproject.org 19 Jan '19

19 Jan '19

commit 5b4397bff8f83dced4c415f5232442ae59f5072d Author: Yawning Angel <yawning(a)schwanenlied.me> Date: Sat Jan 19 11:42:24 2019 +0000 Clean up static analysis warnings Mostly but not entirely discarding error return values of things that can not possibly fail despite the API returning errors. --- common/drbg/hash_drbg.go | 2 +- common/ntor/ntor.go | 10 ++++---- common/socks5/rfc1929.go | 4 ++-- common/socks5/socks5.go | 22 +++++++++--------- common/socks5/socks_test.go | 10 +++++--- obfs4proxy/obfs4proxy.go | 32 +++++++++++++------------- obfs4proxy/pt_extras.go | 6 ++--- transports/meeklite/meek.go | 4 ++-- transports/obfs2/obfs2.go | 6 ++--- transports/obfs3/obfs3.go | 8 +++---- transports/obfs4/framing/framing_test.go | 2 +- transports/obfs4/handshake_ntor.go | 24 +++++++++---------- transports/scramblesuit/conn.go | 12 +++++----- transports/scramblesuit/handshake_ticket.go | 10 ++++---- transports/scramblesuit/handshake_uniformdh.go | 14 +++++------ transports/scramblesuit/hkdf_expand.go | 6 ++--- transports/transports.go | 16 +++++++++---- 17 files changed, 99 insertions(+), 89 deletions(-) diff --git a/common/drbg/hash_drbg.go b/common/drbg/hash_drbg.go index ea283ca..3d1a469 100644 --- a/common/drbg/hash_drbg.go +++ b/common/drbg/hash_drbg.go @@ -139,7 +139,7 @@ func (drbg *HashDrbg) Seed(seed int64) { // NextBlock returns the next 8 byte DRBG block. func (drbg *HashDrbg) NextBlock() []byte { - drbg.sip.Write(drbg.ofb[:]) + _, _ = drbg.sip.Write(drbg.ofb[:]) copy(drbg.ofb[:], drbg.sip.Sum(nil)) ret := make([]byte, Size) diff --git a/common/ntor/ntor.go b/common/ntor/ntor.go index d5218db..48508bf 100644 --- a/common/ntor/ntor.go +++ b/common/ntor/ntor.go @@ -385,21 +385,21 @@ func ntorCommon(secretInput bytes.Buffer, id *NodeID, b *PublicKey, x *PublicKey // KEY_SEED = H(secret_input, t_key) h := hmac.New(sha256.New, tKey) - h.Write(secretInput.Bytes()) + _, _ = h.Write(secretInput.Bytes()) tmp := h.Sum(nil) copy(keySeed[:], tmp) // verify = H(secret_input, t_verify) h = hmac.New(sha256.New, tVerify) - h.Write(secretInput.Bytes()) + _, _ = h.Write(secretInput.Bytes()) verify := h.Sum(nil) // auth_input = verify | ID | B | Y | X | PROTOID | "Server" authInput := bytes.NewBuffer(verify) - authInput.Write(suffix.Bytes()) - authInput.Write([]byte("Server")) + _, _ = authInput.Write(suffix.Bytes()) + _, _ = authInput.Write([]byte("Server")) h = hmac.New(sha256.New, tMac) - h.Write(authInput.Bytes()) + _, _ = h.Write(authInput.Bytes()) tmp = h.Sum(nil) copy(auth[:], tmp) diff --git a/common/socks5/rfc1929.go b/common/socks5/rfc1929.go index f8176f1..d7849df 100644 --- a/common/socks5/rfc1929.go +++ b/common/socks5/rfc1929.go @@ -39,8 +39,8 @@ func (req *Request) authRFC1929() (err error) { sendErrResp := func() { // Swallow write/flush errors, the auth failure is the relevant error. resp := []byte{authRFC1929Ver, authRFC1929Fail} - req.rw.Write(resp[:]) - req.flushBuffers() + _, _ = req.rw.Write(resp[:]) + _ = req.flushBuffers() } // The client sends a Username/Password request. diff --git a/common/socks5/socks5.go b/common/socks5/socks5.go index 876f934..a6f785d 100644 --- a/common/socks5/socks5.go +++ b/common/socks5/socks5.go @@ -257,15 +257,15 @@ func (req *Request) readCommand() error { var err error if err = req.readByteVerify("version", version); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } if err = req.readByteVerify("command", cmdConnect); err != nil { - req.Reply(ReplyCommandNotSupported) + _ = req.Reply(ReplyCommandNotSupported) return err } if err = req.readByteVerify("reserved", rsv); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } @@ -273,49 +273,49 @@ func (req *Request) readCommand() error { var atyp byte var host string if atyp, err = req.readByte(); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } switch atyp { case atypIPv4: var addr []byte if addr, err = req.readBytes(net.IPv4len); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } host = net.IPv4(addr[0], addr[1], addr[2], addr[3]).String() case atypDomainName: var alen byte if alen, err = req.readByte(); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } if alen == 0 { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return fmt.Errorf("domain name with 0 length") } var addr []byte if addr, err = req.readBytes(int(alen)); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } host = string(addr) case atypIPv6: var rawAddr []byte if rawAddr, err = req.readBytes(net.IPv6len); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } addr := make(net.IP, net.IPv6len) copy(addr[:], rawAddr[:]) host = fmt.Sprintf("[%s]", addr.String()) default: - req.Reply(ReplyAddressNotSupported) + _ = req.Reply(ReplyAddressNotSupported) return fmt.Errorf("unsupported address type 0x%02x", atyp) } var rawPort []byte if rawPort, err = req.readBytes(2); err != nil { - req.Reply(ReplyGeneralFailure) + _ = req.Reply(ReplyGeneralFailure) return err } port := int(rawPort[0])<<8 | int(rawPort[1]) diff --git a/common/socks5/socks_test.go b/common/socks5/socks_test.go index 720476f..3e331fb 100644 --- a/common/socks5/socks_test.go +++ b/common/socks5/socks_test.go @@ -56,12 +56,16 @@ func (c *testReadWriter) Write(buf []byte) (n int, err error) { return c.writeBuf.Write(buf) } -func (c *testReadWriter) writeHex(str string) (n int, err error) { +func (c *testReadWriter) writeHex(str string) { var buf []byte + var err error + if buf, err = hex.DecodeString(str); err != nil { - return + panic("writeHex: malformed hex: " + err.Error()) + } + if _, err = c.readBuf.Write(buf); err != nil { + panic("writeHex: buffered write failed: " + err.Error()) } - return c.readBuf.Write(buf) } func (c *testReadWriter) readHex() string { diff --git a/obfs4proxy/obfs4proxy.go b/obfs4proxy/obfs4proxy.go index 0770455..6de361b 100644 --- a/obfs4proxy/obfs4proxy.go +++ b/obfs4proxy/obfs4proxy.go @@ -75,23 +75,25 @@ func clientSetup() (launched bool, listeners []net.Listener) { for _, name := range ptClientInfo.MethodNames { t := transports.Get(name) if t == nil { - pt.CmethodError(name, "no such transport is supported") + _ = pt.CmethodError(name, "no such transport is supported") continue } f, err := t.ClientFactory(stateDir) if err != nil { - pt.CmethodError(name, "failed to get ClientFactory") + _ = pt.CmethodError(name, "failed to get ClientFactory") continue } ln, err := net.Listen("tcp", socksAddr) if err != nil { - pt.CmethodError(name, err.Error()) + _ = pt.CmethodError(name, err.Error()) continue } - go clientAcceptLoop(f, ln, ptClientProxy) + go func() { + _ = clientAcceptLoop(f, ln, ptClientProxy) + }() pt.Cmethod(name, socks5.Version(), ln.Addr()) log.Infof("%s - registered listener: %s", name, ln.Addr()) @@ -137,7 +139,7 @@ func clientHandler(f base.ClientFactory, conn net.Conn, proxyURI *url.URL) { args, err := f.ParseArgs(&socksReq.Args) if err != nil { log.Errorf("%s(%s) - invalid arguments: %s", name, addrStr, err) - socksReq.Reply(socks5.ReplyGeneralFailure) + _ = socksReq.Reply(socks5.ReplyGeneralFailure) return } @@ -149,7 +151,7 @@ func clientHandler(f base.ClientFactory, conn net.Conn, proxyURI *url.URL) { // This should basically never happen, since config protocol // verifies this. log.Errorf("%s(%s) - failed to obtain proxy dialer: %s", name, addrStr, log.ElideError(err)) - socksReq.Reply(socks5.ReplyGeneralFailure) + _ = socksReq.Reply(socks5.ReplyGeneralFailure) return } dialFn = dialer.Dial @@ -157,7 +159,7 @@ func clientHandler(f base.ClientFactory, conn net.Conn, proxyURI *url.URL) { remote, err := f.Dial("tcp", socksReq.Target, dialFn, args) if err != nil { log.Errorf("%s(%s) - outgoing connection failed: %s", name, addrStr, log.ElideError(err)) - socksReq.Reply(socks5.ErrorToReplyCode(err)) + _ = socksReq.Reply(socks5.ErrorToReplyCode(err)) return } defer remote.Close() @@ -172,8 +174,6 @@ func clientHandler(f base.ClientFactory, conn net.Conn, proxyURI *url.URL) { } else { log.Infof("%s(%s) - closed connection", name, addrStr) } - - return } func serverSetup() (launched bool, listeners []net.Listener) { @@ -186,23 +186,25 @@ func serverSetup() (launched bool, listeners []net.Listener) { name := bindaddr.MethodName t := transports.Get(name) if t == nil { - pt.SmethodError(name, "no such transport is supported") + _ = pt.SmethodError(name, "no such transport is supported") continue } f, err := t.ServerFactory(stateDir, &bindaddr.Options) if err != nil { - pt.SmethodError(name, err.Error()) + _ = pt.SmethodError(name, err.Error()) continue } ln, err := net.ListenTCP("tcp", bindaddr.Addr) if err != nil { - pt.SmethodError(name, err.Error()) + _ = pt.SmethodError(name, err.Error()) continue } - go serverAcceptLoop(f, ln, &ptServerInfo) + go func() { + _ = serverAcceptLoop(f, ln, &ptServerInfo) + }() if args := f.Args(); args != nil { pt.SmethodArgs(name, ln.Addr(), *args) } else { @@ -262,8 +264,6 @@ func serverHandler(f base.ServerFactory, conn net.Conn, info *pt.ServerInfo) { } else { log.Infof("%s(%s) - closed connection", name, addrStr) } - - return } func copyLoop(a net.Conn, b net.Conn) error { @@ -326,7 +326,7 @@ func main() { // Determine if this is a client or server, initialize the common state. var ptListeners []net.Listener - launched := false + var launched bool isClient, err := ptIsClient() if err != nil { golog.Fatalf("[ERROR]: %s - must be run as a managed transport", execName) diff --git a/obfs4proxy/pt_extras.go b/obfs4proxy/pt_extras.go index f490fbc..dfe6d0f 100644 --- a/obfs4proxy/pt_extras.go +++ b/obfs4proxy/pt_extras.go @@ -43,19 +43,19 @@ import ( func ptEnvError(msg string) error { line := []byte(fmt.Sprintf("ENV-ERROR %s\n", msg)) - pt.Stdout.Write(line) + _, _ = pt.Stdout.Write(line) return errors.New(msg) } func ptProxyError(msg string) error { line := []byte(fmt.Sprintf("PROXY-ERROR %s\n", msg)) - pt.Stdout.Write(line) + _, _ = pt.Stdout.Write(line) return errors.New(msg) } func ptProxyDone() { line := []byte("PROXY DONE\n") - pt.Stdout.Write(line) + _, _ = pt.Stdout.Write(line) } func ptIsClient() (bool, error) { diff --git a/transports/meeklite/meek.go b/transports/meeklite/meek.go index ca52a4a..a99556b 100644 --- a/transports/meeklite/meek.go +++ b/transports/meeklite/meek.go @@ -216,7 +216,7 @@ func (c *meekConn) SetWriteDeadline(t time.Time) error { } func (c *meekConn) enqueueWrite(b []byte) (ok bool) { - defer func() { recover() }() + defer func() { _ = recover() }() c.workerWrChan <- b return true } @@ -273,7 +273,7 @@ loop: // If the poll interval has elapsed, issue a request. case sndBuf = <-c.workerWrChan: // If there is data pending a send, issue a request. - case _ = <-c.workerCloseChan: + case <-c.workerCloseChan: break loop } diff --git a/transports/obfs2/obfs2.go b/transports/obfs2/obfs2.go index 66e0dbb..7eaaa96 100644 --- a/transports/obfs2/obfs2.go +++ b/transports/obfs2/obfs2.go @@ -362,9 +362,9 @@ func mac(s, x []byte) []byte { // H(x) is SHA256 of x. // MAC(s, x) = H(s | x | s) h := sha256.New() - h.Write(s) - h.Write(x) - h.Write(s) + _, _ = h.Write(s) + _, _ = h.Write(x) + _, _ = h.Write(s) return h.Sum(nil) } diff --git a/transports/obfs3/obfs3.go b/transports/obfs3/obfs3.go index f25d1bd..26b4728 100644 --- a/transports/obfs3/obfs3.go +++ b/transports/obfs3/obfs3.go @@ -235,17 +235,17 @@ func (conn *obfs3Conn) kdf(sharedSecret []byte) error { // RESP_KEY = RESP_SECRET[:KEYLEN] // RESP_COUNTER = RESP_SECRET[KEYLEN:] initHmac := hmac.New(sha256.New, sharedSecret) - initHmac.Write([]byte(initiatorKdfString)) + _, _ = initHmac.Write([]byte(initiatorKdfString)) initSecret := initHmac.Sum(nil) initHmac.Reset() - initHmac.Write([]byte(initiatorMagicString)) + _, _ = initHmac.Write([]byte(initiatorMagicString)) initMagic := initHmac.Sum(nil) respHmac := hmac.New(sha256.New, sharedSecret) - respHmac.Write([]byte(responderKdfString)) + _, _ = respHmac.Write([]byte(responderKdfString)) respSecret := respHmac.Sum(nil) respHmac.Reset() - respHmac.Write([]byte(responderMagicString)) + _, _ = respHmac.Write([]byte(responderMagicString)) respMagic := respHmac.Sum(nil) // The INIT_KEY value keys a block cipher (in CTR mode) used to diff --git a/transports/obfs4/framing/framing_test.go b/transports/obfs4/framing/framing_test.go index 03e0d3b..f34a3a6 100644 --- a/transports/obfs4/framing/framing_test.go +++ b/transports/obfs4/framing/framing_test.go @@ -158,7 +158,7 @@ func BenchmarkEncoder_Encode(b *testing.B) { b.Fatal("buffer.Read() failed:", err) } - n, err = encoder.Encode(frame[:], chopBuf[:n]) + n, _ = encoder.Encode(frame[:], chopBuf[:n]) transfered += n - FrameOverhead } if transfered != len(payload) { diff --git a/transports/obfs4/handshake_ntor.go b/transports/obfs4/handshake_ntor.go index 99f3925..6629c46 100644 --- a/transports/obfs4/handshake_ntor.go +++ b/transports/obfs4/handshake_ntor.go @@ -137,7 +137,7 @@ func (hs *clientHandshake) generateHandshake() ([]byte, error) { var buf bytes.Buffer hs.mac.Reset() - hs.mac.Write(hs.keypair.Representative().Bytes()[:]) + _, _ = hs.mac.Write(hs.keypair.Representative().Bytes()[:]) mark := hs.mac.Sum(nil)[:markLength] // The client handshake is X | P_C | M_C | MAC(X | P_C | M_C | E) where: @@ -161,9 +161,9 @@ func (hs *clientHandshake) generateHandshake() ([]byte, error) { // Calculate and write the MAC. hs.mac.Reset() - hs.mac.Write(buf.Bytes()) + _, _ = hs.mac.Write(buf.Bytes()) hs.epochHour = []byte(strconv.FormatInt(getEpochHour(), 10)) - hs.mac.Write(hs.epochHour) + _, _ = hs.mac.Write(hs.epochHour) buf.Write(hs.mac.Sum(nil)[:macLength]) return buf.Bytes(), nil @@ -185,7 +185,7 @@ func (hs *clientHandshake) parseServerHandshake(resp []byte) (int, []byte, error // Derive the mark. hs.mac.Reset() - hs.mac.Write(hs.serverRepresentative.Bytes()[:]) + _, _ = hs.mac.Write(hs.serverRepresentative.Bytes()[:]) hs.serverMark = hs.mac.Sum(nil)[:markLength] } @@ -201,8 +201,8 @@ func (hs *clientHandshake) parseServerHandshake(resp []byte) (int, []byte, error // Validate the MAC. hs.mac.Reset() - hs.mac.Write(resp[:pos+markLength]) - hs.mac.Write(hs.epochHour) + _, _ = hs.mac.Write(resp[:pos+markLength]) + _, _ = hs.mac.Write(hs.epochHour) macCmp := hs.mac.Sum(nil)[:macLength] macRx := resp[pos+markLength : pos+markLength+macLength] if !hmac.Equal(macCmp, macRx) { @@ -262,7 +262,7 @@ func (hs *serverHandshake) parseClientHandshake(filter *replayfilter.ReplayFilte // Derive the mark. hs.mac.Reset() - hs.mac.Write(hs.clientRepresentative.Bytes()[:]) + _, _ = hs.mac.Write(hs.clientRepresentative.Bytes()[:]) hs.clientMark = hs.mac.Sum(nil)[:markLength] } @@ -282,8 +282,8 @@ func (hs *serverHandshake) parseClientHandshake(filter *replayfilter.ReplayFilte // Allow epoch to be off by up to a hour in either direction. epochHour := []byte(strconv.FormatInt(getEpochHour()+int64(off), 10)) hs.mac.Reset() - hs.mac.Write(resp[:pos+markLength]) - hs.mac.Write(epochHour) + _, _ = hs.mac.Write(resp[:pos+markLength]) + _, _ = hs.mac.Write(epochHour) macCmp := hs.mac.Sum(nil)[:macLength] macRx := resp[pos+markLength : pos+markLength+macLength] if hmac.Equal(macCmp, macRx) { @@ -329,7 +329,7 @@ func (hs *serverHandshake) generateHandshake() ([]byte, error) { var buf bytes.Buffer hs.mac.Reset() - hs.mac.Write(hs.keypair.Representative().Bytes()[:]) + _, _ = hs.mac.Write(hs.keypair.Representative().Bytes()[:]) mark := hs.mac.Sum(nil)[:markLength] // The server handshake is Y | AUTH | P_S | M_S | MAC(Y | AUTH | P_S | M_S | E) where: @@ -355,8 +355,8 @@ func (hs *serverHandshake) generateHandshake() ([]byte, error) { // Calculate and write the MAC. hs.mac.Reset() - hs.mac.Write(buf.Bytes()) - hs.mac.Write(hs.epochHour) // Set in hs.parseClientHandshake() + _, _ = hs.mac.Write(buf.Bytes()) + _, _ = hs.mac.Write(hs.epochHour) // Set in hs.parseClientHandshake() buf.Write(hs.mac.Sum(nil)[:macLength]) return buf.Bytes(), nil diff --git a/transports/scramblesuit/conn.go b/transports/scramblesuit/conn.go index 335be6e..715d20a 100644 --- a/transports/scramblesuit/conn.go +++ b/transports/scramblesuit/conn.go @@ -245,7 +245,7 @@ func (conn *ssConn) makePacket(w io.Writer, pktType byte, data []byte, padLen in // Encrypt the packet, and calculate the MAC. conn.txCrypto.s.XORKeyStream(pkt, pkt) conn.txCrypto.mac.Reset() - conn.txCrypto.mac.Write(pkt) + _, _ = conn.txCrypto.mac.Write(pkt) mac := conn.txCrypto.mac.Sum(nil)[:macLength] // Write out MAC | Packet. Note that this does not go onto the network @@ -273,7 +273,7 @@ func (conn *ssConn) readPackets() error { break } mac := make([]byte, macLength) - conn.receiveBuffer.Read(mac) + _, _ = conn.receiveBuffer.Read(mac) conn.receiveState.mac = mac } @@ -283,12 +283,12 @@ func (conn *ssConn) readPackets() error { break } hdr := make([]byte, pktHdrLength) - conn.receiveBuffer.Read(hdr) + _, _ = conn.receiveBuffer.Read(hdr) // Add the encrypted packet header to the HMAC instance, and then // decrypt it so that the length of the packet can be determined. conn.rxCrypto.mac.Reset() - conn.rxCrypto.mac.Write(hdr) + _, _ = conn.rxCrypto.mac.Write(hdr) conn.rxCrypto.s.XORKeyStream(hdr, hdr) // Store the plaintext packet header, and host byte order length @@ -311,8 +311,8 @@ func (conn *ssConn) readPackets() error { break } data = make([]byte, conn.receiveState.totalLen) - conn.receiveBuffer.Read(data) - conn.rxCrypto.mac.Write(data) + _, _ = conn.receiveBuffer.Read(data) + _, _ = conn.rxCrypto.mac.Write(data) conn.rxCrypto.s.XORKeyStream(data, data) } diff --git a/transports/scramblesuit/handshake_ticket.go b/transports/scramblesuit/handshake_ticket.go index 16b57d6..9672e1b 100644 --- a/transports/scramblesuit/handshake_ticket.go +++ b/transports/scramblesuit/handshake_ticket.go @@ -106,7 +106,7 @@ func (s *ssTicketStore) storeTicket(addr net.Addr, rawT []byte) { // are ignored because the handshake code will just use UniformDH if a // ticket is not available. s.store[addr.String()] = t - s.serialize() + _ = s.serialize() } func (s *ssTicketStore) getTicket(addr net.Addr) (*ssTicket, error) { @@ -198,7 +198,7 @@ func (hs *ssTicketClientHandshake) generateHandshake() ([]byte, error) { hs.mac.Reset() // The client handshake is T | P | M | MAC(T | P | M | E) - hs.mac.Write(hs.ticket.ticket[:]) + _, _ = hs.mac.Write(hs.ticket.ticket[:]) m := hs.mac.Sum(nil)[:macLength] p, err := makePad(hs.padLen) if err != nil { @@ -212,9 +212,9 @@ func (hs *ssTicketClientHandshake) generateHandshake() ([]byte, error) { // Calculate and write the MAC. e := []byte(strconv.FormatInt(getEpochHour(), 10)) - hs.mac.Write(p) - hs.mac.Write(m) - hs.mac.Write(e) + _, _ = hs.mac.Write(p) + _, _ = hs.mac.Write(m) + _, _ = hs.mac.Write(e) buf.Write(hs.mac.Sum(nil)[:macLength]) hs.mac.Reset() diff --git a/transports/scramblesuit/handshake_uniformdh.go b/transports/scramblesuit/handshake_uniformdh.go index 3e8ed59..5a79d64 100644 --- a/transports/scramblesuit/handshake_uniformdh.go +++ b/transports/scramblesuit/handshake_uniformdh.go @@ -76,7 +76,7 @@ func (hs *ssDHClientHandshake) generateHandshake() ([]byte, error) { if err != nil { return nil, err } - hs.mac.Write(x) + _, _ = hs.mac.Write(x) mC := hs.mac.Sum(nil)[:macLength] pC, err := makePad(hs.padLen) if err != nil { @@ -90,9 +90,9 @@ func (hs *ssDHClientHandshake) generateHandshake() ([]byte, error) { // Calculate and write the MAC. hs.epochHour = []byte(strconv.FormatInt(getEpochHour(), 10)) - hs.mac.Write(pC) - hs.mac.Write(mC) - hs.mac.Write(hs.epochHour) + _, _ = hs.mac.Write(pC) + _, _ = hs.mac.Write(mC) + _, _ = hs.mac.Write(hs.epochHour) buf.Write(hs.mac.Sum(nil)[:macLength]) return buf.Bytes(), nil @@ -113,7 +113,7 @@ func (hs *ssDHClientHandshake) parseServerHandshake(resp []byte) (int, []byte, e return 0, nil, err } hs.mac.Reset() - hs.mac.Write(y) + _, _ = hs.mac.Write(y) hs.serverMark = hs.mac.Sum(nil)[:macLength] } @@ -136,8 +136,8 @@ func (hs *ssDHClientHandshake) parseServerHandshake(resp []byte) (int, []byte, e pos += uniformdh.Size // Validate the MAC. - hs.mac.Write(resp[uniformdh.Size : pos+macLength]) - hs.mac.Write(hs.epochHour) + _, _ = hs.mac.Write(resp[uniformdh.Size : pos+macLength]) + _, _ = hs.mac.Write(hs.epochHour) macCmp := hs.mac.Sum(nil)[:macLength] macRx := resp[pos+macLength : pos+2*macLength] if !hmac.Equal(macCmp, macRx) { diff --git a/transports/scramblesuit/hkdf_expand.go b/transports/scramblesuit/hkdf_expand.go index 9626b38..5f4f4b4 100644 --- a/transports/scramblesuit/hkdf_expand.go +++ b/transports/scramblesuit/hkdf_expand.go @@ -50,9 +50,9 @@ func hkdfExpand(hashFn func() hash.Hash, prk []byte, info []byte, l int) []byte ctr := byte(1) for toAppend > 0 { h.Reset() - h.Write(t) - h.Write(info) - h.Write([]byte{ctr}) + _, _ = h.Write(t) + _, _ = h.Write(info) + _, _ = h.Write([]byte{ctr}) t = h.Sum(nil) ctr++ diff --git a/transports/transports.go b/transports/transports.go index 6301c8b..921666a 100644 --- a/transports/transports.go +++ b/transports/transports.go @@ -84,11 +84,17 @@ func Get(name string) base.Transport { // Init initializes all of the integrated transports. func Init() error { - Register(new(meeklite.Transport)) - Register(new(obfs2.Transport)) - Register(new(obfs3.Transport)) - Register(new(obfs4.Transport)) - Register(new(scramblesuit.Transport)) + for _, v := range []base.Transport{ + new(meeklite.Transport), + new(obfs2.Transport), + new(obfs3.Transport), + new(obfs4.Transport), + new(scramblesuit.Transport), + } { + if err := Register(v); err != nil { + return err + } + } return nil }

1 0

[translation/tpo-web_completed] Update translations for tpo-web_completed
by translation＠torproject.org 19 Jan '19

19 Jan '19

commit b15d1f27c1aefef4e4585874f2c016502a02876a Author: Translation commit bot <translation(a)torproject.org> Date: Sat Jan 19 10:19:27 2019 +0000 Update translations for tpo-web_completed --- contents.pot | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/contents.pot b/contents.pot index 0701a392b..44efe6d38 100644 --- a/contents.pot +++ b/contents.pot @@ -3,7 +3,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: en <LL(a)li.org>\n" @@ -659,15 +659,10 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" +" both in politics and technology." msgstr "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." -msgstr "in politics and technology." +" both in politics and technology." #: https//torproject.org/about/people/antonela/ #: (content/about/people/antonela/contents+en.lrperson.description) @@ -1896,8 +1891,8 @@ msgstr "Internews Europe" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" -msgstr "Media Democracy Found" +msgid "Media Democracy Fund" +msgstr "Media Democracy Fund" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.description) @@ -2309,10 +2304,28 @@ msgstr "Get monthly updates and opportunities from the Tor Project" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." msgstr "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "Defend yourself." + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "Protect yourself against tracking, surveillance, and censorship." + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "Read the latest release announcements" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" +msgstr "Advanced Install Options & Other Platforms" #: templates/hero-home.html:2 msgid "Browse Privately."

1 0

[translation/tpo-web] Update translations for tpo-web
by translation＠torproject.org 19 Jan '19

19 Jan '19

commit 0fd94dd2d9dbf33027227c45401a14ee2b2e69cc Author: Translation commit bot <translation(a)torproject.org> Date: Sat Jan 19 10:19:19 2019 +0000 Update translations for tpo-web --- contents+de.po | 32 +++++++++++++++++++++----------- contents+es.po | 34 ++++++++++++++++++++++------------ contents+fr.po | 32 +++++++++++++++++++++----------- contents+pt-BR.po | 32 +++++++++++++++++++++----------- contents+ru.po | 32 +++++++++++++++++++++----------- contents+tr.po | 32 +++++++++++++++++++++----------- contents+zh-CN.po | 32 ++++++++++++++++++++++---------- contents.pot | 37 +++++++++++++++++++++++++------------ 8 files changed, 174 insertions(+), 89 deletions(-) diff --git a/contents+de.po b/contents+de.po index 9aa1a9b9d..6a2f524fb 100644 --- a/contents+de.po +++ b/contents+de.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: 2019-01-10 12:38+0000\n" "Last-Translator: Oliver Parczyk, 2019\n" "Language-Team: German (https://www.transifex.com/otf/teams/94225/de/)\n" @@ -599,12 +599,7 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" -msgstr "" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." +" both in politics and technology." msgstr "" #: https//torproject.org/about/people/antonela/ @@ -1621,7 +1616,7 @@ msgstr "" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" +msgid "Media Democracy Fund" msgstr "" #: https//torproject.org/about/sponsors/mdf/ @@ -1964,10 +1959,25 @@ msgstr "" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." +msgstr "" + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "" + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "" + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" msgstr "" -"Markenrechts-, Copyright-Mitteilungen und Regeln für Drittparteien finden " -"sich in unserer " #: templates/hero-home.html:2 msgid "Browse Privately." diff --git a/contents+es.po b/contents+es.po index 1c26523f5..7e2ca492a 100644 --- a/contents+es.po +++ b/contents+es.po @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: 2019-01-10 12:38+0000\n" "Last-Translator: Emma Peel, 2019\n" "Language-Team: Spanish (https://www.transifex.com/otf/teams/94225/es/)\n" @@ -74,7 +74,7 @@ msgstr "Descargar" #: https//torproject.org/download/ (content/download/contents+en.lrpage.body) msgid "Download Tor Browser" -msgstr "Bajarse el navegador Tor" +msgstr "Descargar Tor Browser" #: https//torproject.org/press/ (content/press/contents+en.lrpage.title) msgid "press" @@ -597,12 +597,7 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" -msgstr "" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." +" both in politics and technology." msgstr "" #: https//torproject.org/about/people/antonela/ @@ -1619,7 +1614,7 @@ msgstr "Internews Europe" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" +msgid "Media Democracy Fund" msgstr "" #: https//torproject.org/about/sponsors/mdf/ @@ -1961,10 +1956,25 @@ msgstr "Recibe noticias mensuales y oportunidades del Proyecto Tor" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." +msgstr "" + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "" + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "" + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" msgstr "" -"Se pueden encontrar, la marca registrada, las notas de derechos de autor, y " -"las reglas de uso por terceras partes, en nuestra" #: templates/hero-home.html:2 msgid "Browse Privately." diff --git a/contents+fr.po b/contents+fr.po index 3cf25bc7f..27f9ba580 100644 --- a/contents+fr.po +++ b/contents+fr.po @@ -9,7 +9,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: 2019-01-10 12:38+0000\n" "Last-Translator: Curtis Baltimore <curtisbaltimore(a)protonmail.com>, 2019\n" "Language-Team: French (https://www.transifex.com/otf/teams/94225/fr/)\n" @@ -598,12 +598,7 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" -msgstr "" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." +" both in politics and technology." msgstr "" #: https//torproject.org/about/people/antonela/ @@ -1620,7 +1615,7 @@ msgstr "" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" +msgid "Media Democracy Fund" msgstr "" #: https//torproject.org/about/sponsors/mdf/ @@ -1963,10 +1958,25 @@ msgstr "Recevez les mises à jours et opportunités mensuelles du Projet Tor" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." +msgstr "" + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "" + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "" + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" msgstr "" -"La marque déposée, les droits d’auteurs et de reproduction par un tiers " -"parti peuvent être trouvés dans notre " #: templates/hero-home.html:2 msgid "Browse Privately." diff --git a/contents+pt-BR.po b/contents+pt-BR.po index ed70424f3..ff2a62bf9 100644 --- a/contents+pt-BR.po +++ b/contents+pt-BR.po @@ -11,7 +11,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: 2019-01-10 12:38+0000\n" "Last-Translator: nilson t. c., 2019\n" "Language-Team: Portuguese (Brazil) (https://www.transifex.com/otf/teams/94225/pt_BR/)\n" @@ -600,12 +600,7 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" -msgstr "" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." +" both in politics and technology." msgstr "" #: https//torproject.org/about/people/antonela/ @@ -1622,7 +1617,7 @@ msgstr "" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" +msgid "Media Democracy Fund" msgstr "" #: https//torproject.org/about/sponsors/mdf/ @@ -1964,10 +1959,25 @@ msgstr "Receba atualizações mensais e avisos de oportunidades do Projeto Tor" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." +msgstr "" + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "" + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "" + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" msgstr "" -"Trademark, avisos de direitos autorais, e regras de uso para terceiros podem" -" ser encontradas em nosso" #: templates/hero-home.html:2 msgid "Browse Privately." diff --git a/contents+ru.po b/contents+ru.po index 5e9109022..6dc6115a0 100644 --- a/contents+ru.po +++ b/contents+ru.po @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: 2019-01-10 12:38+0000\n" "Last-Translator: Emma Peel, 2019\n" "Language-Team: Russian (https://www.transifex.com/otf/teams/94225/ru/)\n" @@ -597,12 +597,7 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" -msgstr "" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." +" both in politics and technology." msgstr "" #: https//torproject.org/about/people/antonela/ @@ -1619,7 +1614,7 @@ msgstr "" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" +msgid "Media Democracy Fund" msgstr "" #: https//torproject.org/about/sponsors/mdf/ @@ -1961,10 +1956,25 @@ msgstr "Получайте ежемесячные обновления и воз #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." +msgstr "" + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "" + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "" + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" msgstr "" -"Товарные знаки, уведомления об авторских правах и правила использования " -"третьими лицами можно найти в нашем " #: templates/hero-home.html:2 msgid "Browse Privately." diff --git a/contents+tr.po b/contents+tr.po index 6bcf00868..dfe245c35 100644 --- a/contents+tr.po +++ b/contents+tr.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: 2019-01-10 12:38+0000\n" "Last-Translator: T. E. Kalayci <tekrei(a)fsfe.org>, 2019\n" "Language-Team: Turkish (https://www.transifex.com/otf/teams/94225/tr/)\n" @@ -599,12 +599,7 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" -msgstr "" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." +" both in politics and technology." msgstr "" #: https//torproject.org/about/people/antonela/ @@ -1621,7 +1616,7 @@ msgstr "" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" +msgid "Media Democracy Fund" msgstr "" #: https//torproject.org/about/sponsors/mdf/ @@ -1965,10 +1960,25 @@ msgstr "" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." +msgstr "" + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "" + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "" + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" msgstr "" -"Üçüncü partiler tarafından kullanım için patent, telif hakkı ve kurallar " -"şurada bulunabilir " #: templates/hero-home.html:2 msgid "Browse Privately." diff --git a/contents+zh-CN.po b/contents+zh-CN.po index 795c5ab19..7889b8e0d 100644 --- a/contents+zh-CN.po +++ b/contents+zh-CN.po @@ -10,7 +10,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: 2019-01-10 12:38+0000\n" "Last-Translator: Xiaoyu Huang <007pig(a)gmail.com>, 2019\n" "Language-Team: Chinese (China) (https://www.transifex.com/otf/teams/94225/zh_CN/)\n" @@ -599,12 +599,7 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" -msgstr "" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." +" both in politics and technology." msgstr "" #: https//torproject.org/about/people/antonela/ @@ -1621,7 +1616,7 @@ msgstr "" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" +msgid "Media Democracy Fund" msgstr "" #: https//torproject.org/about/sponsors/mdf/ @@ -1959,8 +1954,25 @@ msgstr "订阅我们每个月发布的消息和机遇" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " -msgstr "商标保护，专利保护，以及第三方使用规则可以在这里找到 " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." +msgstr "" + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "" + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "" + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" +msgstr "" #: templates/hero-home.html:2 msgid "Browse Privately." diff --git a/contents.pot b/contents.pot index 0701a392b..44efe6d38 100644 --- a/contents.pot +++ b/contents.pot @@ -3,7 +3,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2019-01-19 07:40+CET\n" +"POT-Creation-Date: 2019-01-19 11:06+CET\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: en <LL(a)li.org>\n" @@ -659,15 +659,10 @@ msgstr "" #: (content/about/people/andreas/contents+en.lrperson.description) msgid "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" +" both in politics and technology." msgstr "" "Works at the intersection of security, privacy, data integrity and anonymity" -" both" - -#: https//torproject.org/about/people/andreas/ -#: (content/about/people/andreas/contents+en.lrperson.description) -msgid "in politics and technology." -msgstr "in politics and technology." +" both in politics and technology." #: https//torproject.org/about/people/antonela/ #: (content/about/people/antonela/contents+en.lrperson.description) @@ -1896,8 +1891,8 @@ msgstr "Internews Europe" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.name) -msgid "Media Democracy Found" -msgstr "Media Democracy Found" +msgid "Media Democracy Fund" +msgstr "Media Democracy Fund" #: https//torproject.org/about/sponsors/mdf/ #: (content/about/sponsors/mdf/contents+en.lrsponsor.description) @@ -2309,10 +2304,28 @@ msgstr "Get monthly updates and opportunities from the Tor Project" #: templates/footer.html:46 msgid "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." msgstr "" "Trademark, copyright notices, and rules for use by third parties can be " -"found in our " +"found in our <a href=\"https://www.torproject.org/docs/trademark-faq\" " +"target=\"_blank\" class=\"text-primary-light\">FAQ</a>." + +#: templates/hero-download.html:2 +msgid "Defend yourself." +msgstr "Defend yourself." + +#: templates/hero-download.html:5 +msgid "Protect yourself against tracking, surveillance, and censorship." +msgstr "Protect yourself against tracking, surveillance, and censorship." + +#: templates/hero-download.html:34 +msgid "Read the latest release announcements" +msgstr "Read the latest release announcements" + +#: templates/hero-download.html:35 +msgid "Advanced Install Options & Other Platforms" +msgstr "Advanced Install Options & Other Platforms" #: templates/hero-home.html:2 msgid "Browse Privately."

1 0

[research-web/master] Add dos-censorship-report1.
by karsten＠torproject.org 19 Jan '19

19 Jan '19

commit 03dd6b869447348a0de0a429ab8b52068a1f83ea Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Sat Jan 19 09:44:33 2019 +0100 Add dos-censorship-report1. --- techreports.bib | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/techreports.bib b/techreports.bib index 8841ce0..7e0a90e 100644 --- a/techreports.bib +++ b/techreports.bib @@ -8,6 +8,16 @@ url = {https://research.torproject.org/techreports/modern-collector-2018-12-19.pdf}, } +@techreport{tor-2018-11-001, + author = {Antonela Debiasi and Roger Dingledine and Arthur Edelstein and Alexander F\ae r\o y and Matthew Finkel and David Goulet and Kat Hanna and Maggie Haughey and George Kadianakis and Iain R. Learmonth and Alison Macrina and Maria Xynou}, + title = {Addressing Denial of Service Attacks on Free and Open Communication on the Internet}, + institution = {The Tor Project}, + number = {2018-11-001}, + year = {2018}, + month = {November}, + url = {https://research.torproject.org/techreports/dos-censorship-report1-2018-11-19.pdf}, +} + @techreport{tor-2017-04-001, author = {Karin Herm}, title = {Privacy analysis of {Tor}'s in-memory statistics},

1 0

[tech-reports/master] Add Sponsor 19 report 1.
by karsten＠torproject.org 19 Jan '19

19 Jan '19

commit 9a35eec4fc4af02922660ef3d1edc6d241451fab Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 15 15:28:46 2019 +0100 Add Sponsor 19 report 1. Contains all files from ssh://git@git-rw.torproject.org/sponsor19 commit 20fc6f9 to successfully compile the report. Any formatting changes that turn this report into a Tor tech report follow in a separate commit. --- 2018/sponsor19/references.bib | 575 + 2018/sponsor19/report1/Makefile | 7 + 2018/sponsor19/report1/acknowledgements.tex | 4 + 2018/sponsor19/report1/conclusion.tex | 31 + 2018/sponsor19/report1/intro.tex | 105 + 2018/sponsor19/report1/report1.tex | 360 + 2018/sponsor19/report1/task10.tex | 198 + ...ileBroadbandInternetPenetrationWorldMap2012.png | Bin 0 -> 171573 bytes 2018/sponsor19/report1/task10c.tex | 131 + 2018/sponsor19/report1/task11.tex | 653 + .../report1/task11a/cn-success-failure.png | Bin 0 -> 8225 bytes .../report1/task11a/eg-success-failure.png | Bin 0 -> 8956 bytes .../report1/task11a/tr-success-failure.png | Bin 0 -> 9312 bytes 2018/sponsor19/report1/task11a/ve-tor-metrics.png | Bin 0 -> 54726 bytes ...ionperf-latencies-2017-04-15-2018-10-12-all.png | Bin 0 -> 169867 bytes ...rf-public-2009-06-10-2017-05-01-torperf-5mb.png | Bin 0 -> 49646 bytes ...s-relay-country-ug-2018-05-01-2018-08-01-on.png | Bin 0 -> 47276 bytes ...s-relay-country-ve-2018-07-14-2018-10-10-on.png | Bin 0 -> 72514 bytes 2018/sponsor19/report1/task6.tex | 451 + 2018/sponsor19/report1/task6/bw.png | Bin 0 -> 58274 bytes 2018/sponsor19/report1/task6/exit-prob.png | Bin 0 -> 48462 bytes 2018/sponsor19/report1/task6/hs-2018-dos.png | Bin 0 -> 28785 bytes 2018/sponsor19/report1/task6/network.png | Bin 0 -> 40829 bytes 2018/sponsor19/report1/task6/sefnit.png | Bin 0 -> 23481 bytes 2018/sponsor19/report1/task6/user-bridge.png | Bin 0 -> 31163 bytes 2018/sponsor19/report1/task6/user.png | Bin 0 -> 26832 bytes 2018/sponsor19/report1/task7a.tex | 255 + .../sponsor19/report1/task7a/obfsproxy_diagram.png | Bin 0 -> 6405 bytes 2018/sponsor19/report1/task7b.tex | 257 + .../report1/task7b/onion-circuit-display.png | Bin 0 -> 651039 bytes .../report1/task7b/threat-model-uganda-debrief.png | Bin 0 -> 245780 bytes 2018/sponsor19/report1/task8.tex | 158 + 2018/sponsor19/report1/task8/researchportal.png | Bin 0 -> 103265 bytes 2018/sponsor19/report1/task9.tex | 318 + 2018/sponsor19/rfc.bib | 181559 ++++++++++++++++++ 2018/sponsor19/sponsor19.bib | 738 + 2018/sponsor19/torlogo.png | Bin 0 -> 60005 bytes 2018/sponsor19/tortechreports.bib | 461 + 38 files changed, 186261 insertions(+) diff --git a/2018/sponsor19/references.bib b/2018/sponsor19/references.bib new file mode 100644 index 0000000..221bf15 --- /dev/null +++ b/2018/sponsor19/references.bib @@ -0,0 +1,575 @@ +@string{acsac-long = {Annual Computer Security Applications Conference (ACSAC)}} +@string{cacm-long = {Communications of the ACM}} +@string{ccs-long = {ACM Conference on Computer and Communications Security (CCS)}} +@string{conext-long = {ACM International Conference on Emerging Networking EXperiments and Technologies (CoNEXT)}} +@string{crypto-long = {Annual International Cryptology Conference (CRYPTO)}} +@string{cse-long = {International Conference on Computational Science and Engineering (CSE)}} +@string{cset-long = {USENIX Workshop on Cyber Security Experimentation and Test (CSET)}} +@string{esorics-long = {European Symposium on Research in Computer Security (ESORICS)}} +@string{eurocrypt-long = {Advances in Cryptology (Eurocrypt)}} +@string{evt-long = {USENIX/ACCURATE Electronic Voting Technology Workshop (EVT)}} +@string{fc-long = {Financial Cryptography and Data Security (FC)}} +@string{foci-long = {USENIX Workshop on Free and Open Communications on the Internet (FOCI)}} +@string{focs-long = {IEEE Symposium on Foundations of Computer Science (FOCS)}} +@string{hotnets-long = {ACM Workshop on Hot Topics in Networks (HotNets)}} +@string{hotsec-long = {USENIX Workshop on Hot Topics in Security (HotSec)}} +@string{hotpets-long = {Workshop on Hot Topics in Privacy Enhancing Technologies (HotPETs)}} +@string{icalp-long = {International Colloquium on Automata, Languages and Programming (ICALP)}} +@string{icdcs-long = {International Conference on Distributed Computing Systems (ICDCS)}} +@string{icde-long = {International Conference on Data Engineering (ICDE)}} +@string{icnp-long = {International Conference on Network Protocols (ICNP)}} +@string{imc-long = {ACM SIGCOMM Conference on Internet Measurement (IMC)}} +@string{infocom-long = {IEEE International Conference on Computer Communications (INFOCOM)}} +@string{ipdps-long = {IEEE International Parallel \& Distributed Processing Symposium (IPDPS)}} +@string{iptps-long = {International Workshop on Peer-to-Peer Systems (IPTPS)}} +@string{ipwe-long = {IEEE International Workshop on Privacy Engineering (IWPE)}} +@string{micro-long = {IEEE/ACM International Symposium on Microarchitecture (MICRO)}} +@string{mobicom-long = {International Conference on Mobile Computing and Networking (MOBICOM)}} +@string{mobisys-long = {ACM International Conference on Mobile Systems, Applications, and Services (MobiSys)}} +@string{ndss-long = {Network and Distributed System Security Symposium (NDSS)}} +@string{nsdi-long = {USENIX Symposium on Networked Systems Design and Implementation (NSDI)}} +@string{nss-long = {IEEE Network and System Security (NSS)}} +@string{oakland-long = {IEEE Symposium on Security and Privacy (S\&P)}} +@string{osdi-long = {USENIX Symposium on Operating System Design and Implementation (OSDI)}} +@string{pet-long = {Privacy Enhancing Technologies (PET)}} +@string{pets-long = {Privacy Enhancing Technologies Symposium (PETS)}} +@string{popets-long = {Proceedings on Privacy Enhancing Technologies (PoPETs)}} +@string{popl-long = {Symposium on Principles of Programming Languages (POPL)}} +@string{presto-long = {ACM Workshop on Programmable Routers for Extensible Services of Tomorrow (PRESTO)}} +@string{raid-long = {International Symposium on Recent Advances in Intrusion Detection (RAID)}} +@string{securecomm-long = {ICST Conference on Security and Privacy in Communication Networks (SecureComm)}} +@string{sigcomm-long = {Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications (SIGCOMM)}} +@string{sigir-long = {ACM Conference on Research and Development in Information Retrieval (SIGIR)}} +@string{sigkdd-long = {International Conference on Knowledge Discovery and Data Mining (SIGKDD)}} +@string{sigmod-long = {ACM SIGMOD International Conference on Management of Data (SIGMOD)}} +@string{sosp-long = {ACM Symposium on Operating Systems Principles (SOSP)}} +@string{tissec-long = {ACM Transactions on Information and System Security (TISSEC)}} +@string{tocs-long = {ACM Transactions on Computer Systems (TOCS)}} +@string{usenix-sec-long = {USENIX Security Symposium (USENIX)}} +@string{usenix-tech-long = {USENIX Annual Technical Conference (USENIX-ATC)}} +@string{vldb-long = {International Conference on Very Large Data Bases (VLDB)}} +@string{weis-long = {Workshop on the Economics of Information Security (WEIS)}} +@string{wpes-long = {ACM Workshop on Privacy in the Electronic Society (WPES)}} +@string{www-long = {World Wide Web Conference (WWW)}} +@string{wecsr-long = {Workshop on Ethics in Computer Security Research (WECSR)}} + +@inproceedings{tor-design, + title = {{Tor}: The Second-Generation Onion Router}, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + booktitle = usenix-sec-long, + year = {2004} +} + +@misc{tor-specs, + title={Tor specifications}, + author={The Tor Project}, + year={2018}, + month={November}, + howpublished={\url{https://spec.torproject.org/}} +} + +@misc{tor-proposals, + title={The Tor Proposal Process}, + author={Nick Mathewson}, + year={2007}, + month={January}, + howpublished={\url{https://gitweb.torproject.org/torspec.git/tree/proposals… +} + +@misc{control-spec, + title={{TC}: A Tor control protocol (Version 1)}, + author={The Tor Project}, + year={2005}, + month={June}, + howpublished={\url{https://spec.torproject.org/control-spec}} +} + +@inproceedings{loesing2010measuring, + author = {Loesing, Karsten and Murdoch, Steven J. and Dingledine, Roger}, + title = {A Case Study on Measuring Statistical Data in the {Tor} Anonymity Network}, + booktitle = fc-long, + year = {2010}, + note = {See also \url{https://metrics.torproject.org}}, +} + +@inproceedings{mccoy-pet2008, + title = {Shining Light in Dark Places: Understanding the {Tor} Network}, + author = {Damon McCoy and Kevin Bauer and Dirk Grunwald and + Tadayoshi Kohno and Douglas Sicker}, + booktitle = pets-long, + year = {2008} +} + +@inproceedings{chaabane2010digging, + title={Digging into anonymous traffic: A deep analysis of the {Tor} anonymizing network}, + author={Chaabane, A. and Manils, P. and Kaafar, M.A.}, + booktitle=nss-long, + year={2010} +} + +@inproceedings{PrivExElahi2014, + author = {Elahi, Tariq and Danezis, George and Goldberg, Ian}, + title = {{PrivEx}: Private Collection of Traffic Statistics for Anonymous Communication Networks}, + booktitle = ccs-long, + year = {2014}, + note = {See also \url{git://git-crysp.uwaterloo.ca/privex}}, +} + +@inproceedings{privcount-ccs2016, + author = {Rob Jansen and Aaron Johnson}, + title = {Safely Measuring {Tor}}, + booktitle = ccs-long, + year = {2016}, + note = {See also \url{https://github.com/privcount}}, +} + +@inproceedings{mani2017historvarepsilon, + title={{HisTor$\varepsilon$}: Differentially Private and Robust Statistics Collection for {Tor}}, + author={Mani, Akshaya and Sherr, Micah}, + booktitle=ndss-long, + year={2017} +} + +@inproceedings{fenske2017distributed, + title={Distributed Measurement with Private Set-Union Cardinality}, + author={Fenske, Ellis and Mani, Akshaya and Johnson, Aaron and Sherr, Micah}, + booktitle=ccs-long, + year={2017} +} + +@inproceedings{deep-corr18, + title={{DeepCorr}: Strong Flow Correlation Attacks on Tor Using Deep Learning}, + author={Milad Nasr and Alireza Bahramali and Amir Houmansadr}, + booktitle=ccs-long, + year={2018} +} + +@conference{jansen2012shadow, + title={{Shadow}: Running {Tor} in a Box for Accurate and Efficient Experimentation}, + author={Rob Jansen and Nicholas Hopper}, + booktitle=ndss-long, + year={2012}, + note = {See also \url{https://shadow.github.io}}, +} + +@inproceedings{jansen-cset2012, + author = {Jansen, Rob and Bauer, Kevin and Hopper, Nicholas and Dingledine, Roger}, + title = {Methodically Modeling the {Tor} Network}, + booktitle = cset-long, + year = {2012}, +} + +@inproceedings{bauer2011experimentor, + title={{ExperimenTor}: A Testbed for Safe and Realistic {Tor} Experimentation.}, + author={Bauer, Kevin S and Sherr, Micah and Grunwald, Dirk}, + booktitle=cset-long, + year={2011}, +} + +@inproceedings{jansen2018insidejob, + author = {Rob Jansen and Marc Juarez and Rafael Galvez and Tariq Elahi and Claudia Diaz}, + title = {{Inside Job}: Applying Traffic Analysis to Measure {Tor} from Within}, + booktitle = ndss-long, + year = {2018}, +} + +@inproceedings{jansen2010recruiting, + title={Recruiting new {Tor} relays with {BRAIDS}}, + author={Jansen, Rob and Hopper, Nicholas and Kim, Yongdae}, + booktitle=ccs-long, + year={2010}, +} + +@article{owen2016empirical, + title={Empirical analysis of {Tor} hidden services}, + author={Owen, Gareth and Savage, Nick}, + journal={IET Information Security}, + volume={10}, + number={3}, + pages={113--118}, + year={2016}, + publisher={IET} +} + +@inproceedings{dwork-dp-icalp2006, + title={Differential Privacy}, + author={Cynthia Dwork}, + booktitle=icalp-long, + year={2006} +} + +@INPROCEEDINGS{bittorrent-perf, +author={A. R. Bharambe and C. Herley and V. N. Padmanabhan}, +title={Analyzing and Improving a BitTorrent Networks Performance Mechanisms}, +booktitle=infocom-long, +year={2006}, +} + +@article{kist-transition-arxiv, + author = {Rob Jansen and Matthew Traudt}, + title = {{Tor}'s Been {KIST:} {A} Case Study of Transitioning {Tor} Research to Practice}, + journal = {CoRR (arXiv)}, + volume = {abs/1709.01044}, + year = {2017}, + url = {http://arxiv.org/abs/1709.01044}, + archivePrefix = {arXiv}, + eprint = {1709.01044}, + timestamp = {Thu, 05 Oct 2017 09:43:03 +0200}, + biburl = {http://dblp.org/rec/bib/journals/corr/abs-1709-01044}, + bibsource = {dblp computer science bibliography, http://dblp.org} +} + +@inproceedings{soghoian-wescr-2011, + author = {Soghoian, Christopher}, + title = {Enforced Community Standards for Research on Users of the {Tor} Anonymity Network}, + booktitle = wecsr-long, + year = {2011} +} + +@inproceedings{ling2014torward, + title={{TorWard}: Discovery of malicious traffic over {Tor}}, + author={Ling, Zhen and Luo, Junzhou and Wu, Kui and Yu, Wei and Fu, Xinwen}, + booktitle=infocom-long, + year={2014}, +} + +@inproceedings{torexptools, + author = {Shirazi, Fatemeh and Goehring, Matthias and Diaz, Claudia}, + title = {{Tor} Experimentation Tools}, + booktitle = ipwe-long, + series = {IWPE '15}, + year = {2015}, + isbn = {978-1-4799-9933-0}, + pages = {206--213}, + numpages = {8}, + url = {http://dx.doi.org/10.1109/SPW.2015.20}, + doi = {10.1109/SPW.2015.20}, + acmid = {2867785}, +} + +@inproceedings{johnson2017avoiding, + title={Avoiding The Man on the Wire: Improving {Tor}'s Security with Trust-Aware Path Selection}, + author={Johnson, Aaron and Jansen, Rob and Jaggard, Aaron D and Feigenbaum, Joan and Syverson, Paul}, + booktitle = ndss-long, + year={2017}, +} + +@article{barton2016denasa, + title={{DeNASA}: Destination-naive {AS}-awareness in anonymous communications}, + author={Barton, Armon and Wright, Matthew}, + journal=popets-long, + volume={2016}, + number={4}, + pages={356--372}, + year={2016}, + publisher={De Gruyter Open} +} + +@inproceedings{alsabah2013path, + title={The path less travelled: Overcoming {Tor}’s bottlenecks with traffic splitting}, + author={AlSabah, Mashael and Bauer, Kevin and Elahi, Tariq and Goldberg, Ian}, + booktitle=pets-long, + pages={143--163}, + year={2013}, + organization={Springer} +} + +@article{lin2016scalable, + title={Scalable and anonymous group communication with {MTor}}, + author={Lin, Dong and Sherr, Micah and Loo, Boon Thau}, + journal=popets-long, + volume={2016}, + number={2}, + pages={22--39}, + year={2016}, + publisher={De Gruyter Open} +} + +@article{johnson2017peerflow, + title={{PeerFlow}: Secure load balancing in {Tor}}, + author={Johnson, Aaron and Jansen, Rob and Hopper, Nicholas and Segal, Aaron and Syverson, Paul}, + journal=popets-long, + volume={2017}, + number={2}, + pages={74--94}, + year={2017}, + publisher={De Gruyter Open} +} + +@inproceedings{jansen2013lira, + title={{LIRA}: Lightweight incentivized routing for anonymity}, + author={Jansen, Rob and Johnson, Aaron and Syverson, Paul}, + booktitle=ndss-long, + year={2013}, +} + +@inproceedings{AlSabah2013pctcp, + author = {AlSabah, Mashael and Goldberg, Ian}, + title = {{PCTCP}: Per-circuit TCP-over-IPsec Transport for Anonymous Communication Overlay Networks}, + booktitle =ccs-long, + year = {2013}, +} + +@inproceedings{geddes2014imux, + title={{IMUX}: Managing {Tor} connections from two to infinity, and beyond}, + author={Geddes, John and Jansen, Rob and Hopper, Nicholas}, + booktitle=wpes-long, + pages={181--190}, + year={2014}, + organization={ACM} +} + +@inproceedings{gopal2012torchestra, + title={Torchestra: Reducing interactive traffic delays over {Tor}}, + author={Gopal, Deepika and Heninger, Nadia}, + booktitle=wpes-long, + year={2012}, +} + +@inproceedings{AlSabah2012difftor, + author = {AlSabah, Mashael and Bauer, Kevin and Goldberg, Ian}, + title = {Enhancing {Tor}'s Performance Using Real-time Traffic Classification}, + booktitle = {Proceedings of the 2012 ACM Conference on Computer and Communications Security}, + year = {2012}, +} + +@inproceedings{jansen2012throttling, + title={Throttling {Tor} Bandwidth Parasites.}, + author={Jansen, Rob and Syverson, Paul F and Hopper, Nicholas}, + booktitle=usenix-sec-long, + year={2012} +} + +@inproceedings{alsabah2011defenestrator, + title={DefenestraTor: Throwing out windows in {Tor}}, + author={AlSabah, Mashael and Bauer, Kevin and Goldberg, Ian and Grunwald, Dirk and McCoy, Damon and Savage, Stefan and Voelker, Geoffrey M}, + booktitle=pets-long, + pages={134--154}, + year={2011}, + organization={Springer} +} + +@article{alsabah2016performance, + title={Performance and security improvements for {Tor}: A survey}, + author={AlSabah, Mashael and Goldberg, Ian}, + journal={ACM Computing Surveys (CSUR)}, + volume={49}, + number={2}, + pages={32}, + year={2016}, + publisher={ACM} +} + +@inproceedings{jansen2014sniper, + title={The sniper attack: Anonymously deanonymizing and disabling the {Tor} network}, + author={Jansen, Rob and Tschorsch, Florian and Johnson, Aaron and Scheuermann, Bj{\"o}rn}, + year={2014}, + booktitle=ndss-long, +} + +@inproceedings{hopper2014challenges, + title={Challenges in protecting {T}or hidden services from botnet abuse}, + author={Hopper, Nicholas}, + booktitle=fc-long, + pages={316--325}, + year={2014}, + organization={Springer} +} + +@article{Forney73, + author={G. D. Forney}, + journal={Proceedings of the IEEE}, + title={The viterbi algorithm}, + year={1973}, + volume={61}, + number={3}, + pages={268-278}, + doi={10.1109/PROC.1973.9030}, + ISSN={0018-9219}, + month={March}, +} + +@inproceedings{hmmclust, + title={Clustering sequences with hidden Markov models}, + author={Smyth, Padhraic}, + booktitle={Advances in neural information processing systems}, + pages={648--654}, + year={1997} +} + +@inproceedings{sony2000traffic, + title={Traffic data repository at the WIDE project}, + author={Sony, CSL and Cho, Kenjiro}, + booktitle={Proceedings of USENIX 2000 Annual Technical Conference: FREENIX Track}, + pages={263--270}, + year={2000} +} + +@misc{widedump, + title={Traffic Trace Info, 2016-07-08}, + author={WIDE Project, The}, + year={2016}, + month={July}, + howpublished={\url{http://mawi.wide.ad.jp/mawi/samplepoint-F/2016/201607081400.html}} +} + +@article{rochet2018dropping, + title={Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols}, + author={Rochet, Florentin and Pereira, Olivier}, + journal={Proceedings on Privacy Enhancing Technologies}, + volume={2018}, + number={2}, + pages={27--46}, + year={2018}, + publisher={De Gruyter Open} +} + +@INPROCEEDINGS{mtor-cns15, +author={Lei Yang and Fengjun Li}, +booktitle={2015 IEEE Conference on Communications and Network Security (CNS)}, +title={{mTor: A multipath Tor routing beyond bandwidth throttling}}, +year={2015}, +volume={}, +number={}, +pages={479-487}, +keywords={multipath channels;relay networks (telecommunication);telecommunication network routing;telecommunication scheduling;telecommunication traffic;Shadow simulator;active congestion detection;anonymous communication system;bandwidth throttling;bandwidth-intensive applications;bulk data transfers;circuit-scheduling techniques;interactive traffic;latency-sensitive applications;low-bandwidth Tor relays;mTor;multipath Tor routing;multiple circuits;multiple low-bandwidth relays;self-adaptive pulling scheduling technique;Bandwidth;Communication networks;Conferences;Data transfer;Relays;Security;Streaming media}, +doi={10.1109/CNS.2015.7346860}, +ISSN={}, +month={Sept}, +} + +@INPROCEEDINGS{icoin15, +author={S. Dahal and Junghee Lee and Jungmin Kang and Seokjoo Shin}, +booktitle={2015 International Conference on Information Networking (ICOIN)}, +title={{Analysis on end-to-end node selection probability in Tor network}}, +year={2015}, +volume={}, +number={}, +pages={46-50}, +keywords={computer network security;probability;telecommunication network routing;Shadow simulator;Tor network;Tor simulation;compromised nodes;end-to-end node selection probability;online anonymity;online censorship resistance;open network;selection probability;traffic analysis;Bandwidth;Peer-to-peer computing;Privacy;Relays;Routing;Security;Servers;Shadow;Tor;nodes;selection probability}, +doi={10.1109/ICOIN.2015.7057855}, +ISSN={1550-445X}, +month={Jan},} + +@article{rochet2017waterfilling, + title={Waterfilling: Balancing the {T}or network with maximum diversity}, + author={Rochet, Florentin and Pereira, Olivier}, + journal={Proceedings on Privacy Enhancing Technologies}, + volume={2017}, + number={2}, + pages={4--22}, + year={2017}, + publisher={De Gruyter Open} +} + +@inproceedings{Liu2017a, + author = {Zhuotao Liu and Yushan Liu and Philipp Winter and Prateek Mittal and Yih-Chun Hu}, + title = {{TorPolice}: Towards Enforcing Service-Defined Access Policies for Anonymous Communication in the {Tor} Network}, + booktitle = {International Conference on Network Protocols}, + publisher = {IEEE}, + year = {2017}, + url = {https://nymity.ch/papers/pdf/liu2017a.pdf}, +} + +@inproceedings{geddes2016abra, + title={{ABRA CADABRA: Magically Increasing Network Utilization in Tor by Avoiding Bottlenecks}}, + author={Geddes, John and Schliep, Mike and Hopper, Nicholas}, + booktitle={Proceedings of the 2016 ACM on Workshop on Privacy in the Electronic Society}, + pages={165--176}, + year={2016}, + organization={ACM} +} + +@inproceedings{yang2015enhancing, + title={Enhancing traffic analysis resistance for {T}or hidden services with multipath routing}, + author={Yang, Lei and Li, Fengjun}, + booktitle={International Conference on Security and Privacy in Communication Systems}, + pages={367--384}, + year={2015}, + organization={Springer} +} + +@article{imani2018guard, + title={{Guard Sets in Tor using AS Relationships}}, + author={Imani, Mohsen and Barton, Armon and Wright, Matthew}, + journal={Proceedings on Privacy Enhancing Technologies}, + volume={2018}, + number={1}, + pages={145--165}, + year={2018}, + publisher={De Gruyter Open} +} + +@inproceedings{conrad2014analyzing, + title={{Analyzing the effectiveness of DoS attacks on Tor}}, + author={Conrad, Bernd and Shirazi, Fatemeh}, + booktitle={Proceedings of the 7th International Conference on Security of Information and Networks}, + pages={355}, + year={2014}, + organization={ACM} +} + +@inproceedings{shirazi2015towards, + title={Towards measuring resilience in anonymous communication networks}, + author={Shirazi, Fatemeh and Diaz, Claudia and Wright, Joss}, + booktitle={Proceedings of the 14th ACM Workshop on Privacy in the Electronic Society}, + pages={95--99}, + year={2015}, + organization={ACM} +} + +@inproceedings{eigenspeed-Snader2009, + author = {Snader, Robin and Borisov, Nikita}, + title = {EigenSpeed: Secure Peer-to-peer Bandwidth Evaluation}, + booktitle = iptps-long, + year = {2009} +} + +@inproceedings{fte-usenix14, + author = {Daniel Luchaup and Kevin P. Dyer and Somesh Jha and Thomas Ristenpart and Thomas Shrimpton}, + title = {{LibFTE: A Toolkit for Constructing Practical, Format-Abiding Encryption Schemes}}, + booktitle = {USENIX Security Symposium (USENIX Security)}, + year = {2014}, +} + +@inproceedings{marionette, + Author = {Kevin P. Dyer and Scott E. Coull and Thomas Shrimpton}, + Booktitle = usenix-sec-long, + Date-Added = {2015-08-17 17:54:42 +0000}, + Date-Modified = {2015-08-17 17:55:14 +0000}, + Keywords = {anonymity, programming languages}, + Month = Aug, + Title = {{Marionette: A Programmable Network Traffic Obfuscation System}}, + Year = {2015} +} + +@misc{goptlib, + title={Go {PT} Library}, + author={David Fifield and Yawning Angel}, + howpublished={\url{https://gitweb.torproject.org/pluggable-transports/goptl… +} + +@inproceedings{congestion-longpaths, + title = {A Practical Congestion Attack on {T}or Using Long Paths}, + author = {Nathan Evans and Roger Dingledine and Christian Grothoff}, + booktitle = {Proceedings of the 18th USENIX Security Symposium}, + year = {2009}, + month = {August}, +} + +@inproceedings{torta05, + title = {Low-Cost Traffic Analysis of {Tor}}, + author = {Steven J. Murdoch and George Danezis}, + booktitle = {Proceedings of the 2005 IEEE Symposium on Security and Privacy}, + year = {2005}, + month = {May}, + publisher = {IEEE CS}, +} + +@inproceedings{mikeperry-hotpets09, +author = "Mike Perry", +title = "Tor{F}low: {Tor} Network Analysis", +booktitle = hotpets-long, +year = {2009} +} + diff --git a/2018/sponsor19/report1/Makefile b/2018/sponsor19/report1/Makefile new file mode 100644 index 0000000..556c147 --- /dev/null +++ b/2018/sponsor19/report1/Makefile @@ -0,0 +1,7 @@ + +all: + pdflatex report1 + bibtex report1 + pdflatex report1 + pdflatex report1 + diff --git a/2018/sponsor19/report1/acknowledgements.tex b/2018/sponsor19/report1/acknowledgements.tex new file mode 100644 index 0000000..b284229 --- /dev/null +++ b/2018/sponsor19/report1/acknowledgements.tex @@ -0,0 +1,4 @@ +This research was supported by NSF grants CNS-1526306 and CNS-1619454, +and by DARPA contract HR0011-16-C-0056. Any opinions, findings and +conclusions or recommendations expressed in this material are those of +the author(s) and do not necessarily reflect the views of NSF or DARPA. diff --git a/2018/sponsor19/report1/conclusion.tex b/2018/sponsor19/report1/conclusion.tex new file mode 100644 index 0000000..32350f2 --- /dev/null +++ b/2018/sponsor19/report1/conclusion.tex @@ -0,0 +1,31 @@ +Today, free and open communication on the internet is essential for the growth +and maintenance of strong communities and societies. Threats to this open +communication come from a variety of state and non-state censors. The Tor +network is a robust and highly scaled communications network that protects +communications metadata, and as such has an important role to play in combatting +these denials of service. + +In this report we provide a snapshot of the current state of several research +areas in the Tor ecosystem: pluggable transports that help users evade +censorship of the Tor network; an intuitive user experience that enables real +users to accomplish their goals; expanding the set of applications, especially +on mobile, that can be used safely on the Tor network; Tor performance on +networks with poor resources or that are under DoS attack; measurement of +network resources and of censorship; defense of the Tor network against attack; +and strengthening the ties between the Tor Project and the academic research +community. + +Over the next several months, we will continue our work to make progress in +these areas; future reports will describe that progress. In the pluggable +transport area, Snowflake presents a promising direction. Our work on improving +the user interface for setting up bridges and pluggable transports, along with +the Guardian Project's work on getting Snowflake working on Android should make +this technology more accessible for users. OpenArchive represents a positive +step toward enabling users to upload video from censored regimes. Ongoing work +on improving Tor performance and on protecting the Tor network from attack aims +to make the network more robust. Improvements to network measurement, as well +as adding more realistic tests to OONI Probe will help us detect which +locations are censored and which pluggable transports work from censored +locations. Finally, strengthening our relationship with the academic research +community will ensure that we can continue to advance in these areas as well as +many others. diff --git a/2018/sponsor19/report1/intro.tex b/2018/sponsor19/report1/intro.tex new file mode 100644 index 0000000..de5a4f9 --- /dev/null +++ b/2018/sponsor19/report1/intro.tex @@ -0,0 +1,105 @@ +Article 19 of the Universal Declaration of Human Rights asserts the right for +all people ``to seek, receive and impart information and ideas through any media +regardless of frontiers."~\cite{udhr} And +indeed, around the world, people are trying to safely speak out about their +situations, and safely learn what others have to say. This free and open +communication on the internet is critical to the growth of strong communities +and societies. As the American Library Association wrote in 1953, ``the +suppression of ideas is fatal to a democratic society."~\cite{ftr} + +At the same time, nation-state censors and others attempt to \emph{deny} this +communication, threatening the health and safety of communities. In this +project, we leverage our past work on the Tor anonymity system and the +pluggable transport ecosystem to explore and analyze techniques to +detect, understand, and mitigate these denials of service. In this first +report, we present the +current state-of-play in these areas, as well as some research +directions and plans for future work. In subsequent reports, we will describe +our findings and our progress with work on the project. + +This report is organized as follows: the remainder of this section gives a +brief overview of Tor and describes how it is used to evade censorship; +Section~\ref{chap:better-pts} describes pluggable transports and how Tor +Browser uses them; Section~\ref{chap:more-apps} discusses applications that +currently use the Tor network as well as some challenges to using popular apps +in censored locations; Section~\ref{chap:perf-bad-networks} discusses onion +routing client performance on networks with resource constraints; +Section~\ref{chap:measurement} outlines how we measure key metrics about +the Tor network, including censorship of Tor; +Section~\ref{chap:network-defense} describes some attacks on the Tor network +and how we defend against them; and Section~\ref{chap:stronger-research} +discusses building a stronger relationship between the Tor Project and academic +researchers. + +\section{About Tor} +\label{intro-about-tor} + +The Tor anonymity system~\cite{tor-design} protects internet users from +tracking, surveillance, and censorship. The Tor network is made up of thousands +of volunteer-run \emph{relays}---servers that are usually located in data +centers---distributed across the world that enable users to make private +connections to services on the internet. Currently, the vast majority of +connections to the Tor network are made using the Tor Browser. But a growing +number of applications use the Tor network (see Section~\ref{apps-that-use-tor} +for a list), and we expect that many more will do so in the future. + +When Tor Browser starts up, it connects to a single relay in the Tor network, +known as the \emph{guard} relay. The connection to the guard is always +encrypted, and all web connections are passed through this fully-encrypted +connection so that third parties (such as an ISP) observing the user's internet +connection cannot see which website the user is visiting. + +Then, for each connection to a public website, Tor builds a tunnel through the +guard relay and two other randomly-chosen Tor relays. Connections from Tor +Browser thus pass, encrypted, through three Tor relays before exiting from the +Tor network onto the public internet. The way the encryption works means that +the guard relay can see the address of the computer making the request, but not +the website the user is visiting; the middle relay can see the address of the +guard relay and the address of the third relay (called the \emph{exit relay}); +and the exit relay can see the address of the middle relay as well as the +destination website. + +A Tor connection through a guard relay, a middle relay, and an exit relay +is called a Tor \emph{circuit}. Tor relays are usually part of many Tor +circuits and relay traffic for many Tor users at the same time. + +Tor's \emph{directory authorities} are a group of trusted servers that keep +track of all of the relays that are currently able to help users protect their +privacy. Directory authorities periodically publish a list of the addresses of +these available relays, and applications such as Tor Browser choose relays from +this list when they connect to the Tor network. + +\section{Tor and censorship} +%\label{intro-tor-censorship} + +Governments and other censors use a variety of tools to deny people access to +the free and open internet. As a result, systems for getting around censorship, +including Tor, must adopt a variety of measures as well. + +Because the connection between Tor Browser and the guard relay is encrypted, +parties observing a user's internet connection (such as an ISP) cannot +selectively block connections based on their content or destination. Some +governments and ISPs have responded to this censorship evasion by attempting to +prevent users from connecting to the Tor network in the first place. + +One way to do this blocking is to prevent people from downloading the Tor +Browser by blocking connections to the Tor Project website and its mirrors. We +responded to this concern by launching the \emph{GetTor service}~\cite{gettor}, +which allows users to make a request via email or twitter. The service responds +with a link to a cloud storage site that the user can download Tor Browser +from. + +Another way to block access to the Tor network is to block connections to +addresses published in the publicly available list of Tor relays. Tor +\emph{bridges} are Tor relays that are not in the public list, which makes +blocking them more difficult. How to distribute bridge addresses to users while +keeping them from the censors is discussed in Sections~\ref{bridge-distrib} and +\ref{browser-censorship}. + +More sophisticated censors use \emph{deep packet inspection} (DPI) to recognize +and block connections. This method examines the data moving across the internet +and tries to determine whether it's Tor traffic. To counter this blocking, Tor +uses \emph{pluggable transports}. Pluggable transports disguise the +traffic between the user and a Tor bridge so that it doesn't look like Tor +traffic. Pluggable transports are discussed in Sections~\ref{pt-types} and +\ref{browser-censorship}. diff --git a/2018/sponsor19/report1/report1.tex b/2018/sponsor19/report1/report1.tex new file mode 100644 index 0000000..8b21a70 --- /dev/null +++ b/2018/sponsor19/report1/report1.tex @@ -0,0 +1,360 @@ +\documentclass[twoside,openright,11pt]{report} + + +\newcommand{\todo}[1]{[{\textbf{todo}}: {\em\color{red} #1}]} + +\newcommand{\deliverabletitle}{Interim Report 1} +\newcommand{\deliverabletitleshort}{Interim Report 1} +\newcommand{\reportnumber}{1} +\newcommand{\deliverabledate}{November 2018} + +\newcommand{\eg}{\mbox{e.g.}\xspace} +\newcommand{\ie}{\mbox{i.e.}\xspace} + +\newcommand{\deliverableauthorlist}{ +Antonela Debiasi, Roger Dingledine, Arthur Edelstein, Alexander F\ae r\o y, \\ +Matthew Finkel, David Goulet, Kat Hanna, Maggie Haughey, George Kadianakis, \\ +Iain R. Learmonth, Alison Macrina, Maria Xynou } + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%% LATEX MACHINERY BEGINS HERE - NO USER-SERVICEABLE PARTS INSIDE +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Document geometry +% + +% Set up for letter rather than A4 +\usepackage[left=.75in,right=.75in,top=1in,bottom=1in,foot=48pt]{geometry} + +%\setlength{\textheight}{230mm} +%\setlength{\textwidth}{160mm} +%\setlength{\voffset}{-25mm} +%\setlength{\oddsidemargin}{0mm} +%\setlength{\evensidemargin}{0mm} +\addtolength{\parskip}{0.33\baselineskip} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Package definitions +% + +\usepackage{helvet} +\usepackage{graphicx} +\usepackage{subfigure} +\usepackage{color} +\usepackage{xcolor} +\usepackage{chngcntr} +\usepackage{longtable} +\usepackage{lastpage} +\usepackage{fancyhdr} +\usepackage{setspace} +\usepackage{url} +\usepackage{amsmath} +\usepackage{acronym} +\usepackage{listings} +\usepackage{balance} +\usepackage{array} +\usepackage{hyperref} +\usepackage{xspace} +\usepackage{ccicons} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Font definitions +% +\renewcommand\familydefault{\sfdefault} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Heading style definitions +% + +\setcounter{secnumdepth}{4} + +\makeatletter +\renewcommand{\chapter}{\@startsection{chapter}{0}{0mm} + {\baselineskip}% + {\baselineskip}{\clearpage\LARGE\bf\color{black}}} +\renewcommand{\section}{\@startsection{section}{1}{0mm} + {\baselineskip}% + {\baselineskip}{\LARGE\color{black}}}% +\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm} + {\baselineskip}% + {\baselineskip}{\Large\color{black}}}% +\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm} + {\baselineskip}% + {\baselineskip}{\large\color{black}}}% +\makeatother + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Table of contents styling +% +% Finamore: added dotted lines also for chapters +% solution found at http://tex.stackexchange.com/questions/62438/how-to-add-leaders-to-table-of… +\makeatletter +\renewcommand*\l@chapter[2]{% + \ifnum \c@tocdepth >\m@ne + \addpenalty{-\@highpenalty}% + \vskip 1.0em \@plus\p@ + \setlength\(a)tempdima{1.5em}% + \begingroup + \parindent \z@ \rightskip \@pnumwidth + \parfillskip -\@pnumwidth + \leavevmode %\bfseries + \advance\leftskip\@tempdima + \hskip -\leftskip + #1\nobreak + \xleaders\hbox{$\m@th + \mkern \@dotsep mu\hbox{.}\mkern \@dotsep mu$}\hfill% + \nobreak\hb@xt@\@pnumwidth{\hss #2}\par + \penalty\@highpenalty + \endgroup + \fi} +\renewcommand*\l@section{\@dottedtocline{1}{1.5em}{2.3em}} +\renewcommand*\l@subsection{\@dottedtocline{2}{3.8em}{3.2em}} +\renewcommand*\l@subsubsection{\@dottedtocline{3}{7.0em}{4.1em}} +\renewcommand*\l@paragraph{\@dottedtocline{4}{10em}{5em}} +\renewcommand*\l@subparagraph{\@dottedtocline{5}{12em}{6em}} +\renewcommand*{\@dotsep}{1} +\makeatother + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Header and footer definitions +% + +%\setlength{\headheight}{52pt} +%\setlength{\footskip}{47pt} +\renewcommand{\headrulewidth}{0pt} +\pagestyle{fancyplain} + +%\fancyhead[L]{\textsf{DoS Resilience \\ D\reportnumber ~\deliverabletitleshort}} +\fancyhead[L]{\textsf{Addressing Denial of Service Attacks on Free and Open Communication on the Internet \\ \deliverabletitleshort}} +\fancyhead[R]{\setlength{\unitlength}{1mm} +\begin{picture}(0,0) + %\put(-70,-4){\includegraphics[width=70mm]{logos/EC-H2020.png}} +\end{picture} +} +\fancyfoot[L]{\setlength{\unitlength}{1mm} +\begin{picture}(0,0) + \put(0,6){\includegraphics[width=10mm]{../torlogo.png}} +\end{picture} +} +\fancyfoot[C]{\vspace{-10mm}\textsf{\thepage\hspace{0.3em}of \pageref{LastPage}}} +\fancyfoot[R]{\vspace{-10mm}\textsf{\deliverabledate}} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Miscellaneous document adjustments go here + +% Call the bibliography a references section +\renewcommand*{\bibname}{References} + +% Number figures and tables globally +\counterwithout{figure}{chapter} +\counterwithout{table}{chapter} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Define some colors + +\definecolor{darkred}{RGB}{128, 0, 0} +\definecolor{darkgray}{RGB}{95, 95, 95} + +\definecolor{architecuregreen}{RGB}{135, 222, 170} +\definecolor{experimentationblue}{RGB}{128, 179, 255} +\definecolor{measurementred}{RGB}{255, 128, 128} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Define some useful commands + %\EDNOTE{who}{what} - place an editor's note in the document. + %\INNOTE{who}{what} - place an inline note in the document + +\newcommand{\EDNOTE}[2]{ + \par\large\centerline{ + \mbox{ + \begin{tabular}{ll} + \textsf{\textbf{#1}} & + \fbox{ + \begin{minipage}{0.6\linewidth} + \em\color{red} #2 + \end{minipage} + } + \end{tabular} + }} + \par\vspace{4mm} +} + +\newcommand{\INNOTE}[2]{[\textsf{\textbf{#1}}: {\em\color{red} #2}]} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\acrodef{AQM}{Active Queue Management} +\acrodef{ECN}{Explicit Congestion Notification} +\acrodef{EWMA}{Exponential Weighted Moving Average} +\acrodef{FEC}{Forward Error Correction} +\acrodef{IETF}{Internet Engineering Task Force} +\acrodef{MAMI}{Measurement and Architecture for a Middleboxed Internet} +\acrodef{MCP}{Middlebox Cooperation Protocol} +\acrodef{RED}{Random Early Detection} +\acrodef{RTT}{Round-Trip Time} +\acrodef{TCP}{Transmission Control Protocol} +\acrodef{TTL}{Time-To-Live} +\acrodef{NAT}{Network Address Translation} +\acrodef{UDP}{User Datagram Protocol} +\acrodef{MTU}{Maximum Transmission Unit} +\acrodef{MSS}{Maximum Segment Size} +\acrodef{PMTUD}{Path MTU Discovery} +\acrodef{PLPMTUD}{Packetization Layer Path MTU Discovery} +\acrodef{DPLPMTUD}{Datagram Packetization Layer Path MTU Discovery} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Front page +% +\begin{document} +\thispagestyle{empty} +\parindent0pt + +\newcolumntype{R}[1]{>{\raggedleft}p{#1}} + +%\begin{tabular}{R{130mm} p{26mm}} +% \vspace{0pt} +% {\bf\small\color{darkgray} H2020 European Union funding \\ for Research \& Innovation} +% {\small\color{darkgray} This project has received funding from the funder \\ +% research and innovation programme under grant agreement No $x$ where $x > 0$.} +% +% & +% \vspace{0pt} +% %\includegraphics[width=26mm]{logos/eu_flag_small.jpg} +%\end{tabular} + +\vspace{20mm} + +\begin{center} +\hspace{-3mm}\includegraphics[width=90mm]{../torlogo.png} +\end{center} + +\vspace{5mm} +\centerline{\rule{0em}{1.5em}\LARGE\bf\color{black}Addressing Denial of Service Attacks on} +\vspace{5mm} +\centerline{\rule{0em}{1.5em}\LARGE\bf\color{black}Free and Open Communication on the Internet} +%\vspace{5mm} +%\centerline{\rule{0em}{1.5em}\bf\Large\color{darkgray}H2020-ICT-688421} + +\vspace{20mm} + +\begin{centering} +\fbox{ + \begin{minipage}{\linewidth} + \vspace*{1mm} + \center + \huge\em\bf\color{darkred}\deliverabletitle + \end{minipage} +} +%\centerline{\huge\em\bf\color{sangria}\deliverabletitle} + +\vspace{2mm} + +\fbox{ + \begin{minipage}{\linewidth} + \large\textsf{ + \begin{tabular}{lll} + \textbf{Authors:} + \deliverableauthorlist + \end{tabular}} + \end{minipage} +} + +\vspace{5mm} + +\mbox{\begin{minipage}{\linewidth} + \textsf{\begin{tabular}{ll} + %\textbf{Report Number:} & D\reportnumber \\ + \textbf{Date of Delivery:} \deliverabledate\\ + \\ + \textbf{Distribution Statement A.} Approved for Public Release, Distribution Unlimited \\ + \\ + This work is licensed under a \href{https://creativecommons.org/licenses/by/4.0/legalcode}{Creative Commons Attribution 4.0 International License}. \ccby + \end{tabular}} + +\end{minipage} +} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Disclaimer +% +%\clearpage +% +% \mbox{\begin{minipage}{\linewidth} +% \addcontentsline{toc}{chapter}{Disclaimer} +% {\LARGE\em\bf\color{black}{Disclaimer}} +% +% \vspace{10mm} +% \em{ +% \todo{I guess we need some disclaimer here related to the funding} +% } +% \end{minipage}} + + + \end{centering} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Table of contents +% +\clearpage +\tableofcontents + +\chapter{Introduction} +%\addcontentsline{toc}{chapter}{Introduction} +\label{chap:intro} + +\input{intro.tex} + +\chapter{Better Pluggable Transports for Actively Censored Regimes} +\label{chap:better-pts} + +\section{Bridge distribution and pluggable transports} + +\input{task7a.tex} + +\section{Tor Browser and pluggable transports} + +\input{task7b.tex} + +\chapter{Beyond Web Browsing} +\label{chap:more-apps} + +\input{task9.tex} + +\chapter{Performance Under Resource Constraints} +\label{chap:perf-bad-networks} + +\input{task10.tex} + +\input{task10c.tex} + +\chapter{Network and Censorship Measurement} +\label{chap:measurement} + +\input{task11.tex} + +\chapter{Onion Routing Network Defense} +\label{chap:network-defense} + +\input{task6.tex} + +\chapter{A Stronger Research Community} +\label{chap:stronger-research} + +\input{task8.tex} + +\chapter{Conclusion} +\label{chap:conclusion} + +\input{conclusion.tex} + +\chapter{Acknowledgements} +\input{acknowledgements.tex} + +\bibliographystyle{plain} +\bibliography{../sponsor19,../rfc,../tortechreports,../references} + +\end{document} diff --git a/2018/sponsor19/report1/task10.tex b/2018/sponsor19/report1/task10.tex new file mode 100644 index 0000000..cb05470 --- /dev/null +++ b/2018/sponsor19/report1/task10.tex @@ -0,0 +1,198 @@ +Connections through the Tor network are usually slower than direct connections +between a user and a destination on the internet. A big part of this can be +explained by not enough resources being available on Tor relays, but other +factors are also at play~\cite{why-slow}, and can be particularly severe for +users with bad internet connections~\cite{pets2011-defenestrator}. In addition, +load on the network itself, including load created by an attacker or load +targeted at particular relays~\cite{torspinISC08}, can affect the performance +of the whole system. We need to better understand all of the factors that +contribute to poor performance for our users. + +%Several factors contribute to making Tor connections less efficient than a +%direct connection to the final destination~\cite{why-slow}, and while a +%big part of that difference can be explained by the resources that are available +%at the Tor relays (see Section \ref{sec:network-health}), some of these +%performance factors are particularly severe on bad network +%connections~\cite{pets2011-defenestrator}. At the same time, we need to better +%understand how load on the network itself, including load created by an +%attacker or load targeted at particular relays~\cite{torspinISC08}, can impact +%all parts of the system. +% + +\section{Performance in resource constrained access networks} + +In the more developed world, recent advances in wired broadband networks and +cellular networks have led to faster speed when connecting to the internet. But +everyone has not seen these improvements. Connections over old DSL +infrastructure have hardly improved in over a decade, and some people can't +even get cellular data service. There is a large gap between the fastest and +the slowest service\textemdash a gap that continues to +deepen~\cite{HILBERT2016567}. + +In the developed world, people usually had wired internet access first and +then got mobile (cellular) internet devices later. But some less developed +countries are skipping the construction of wired broadband networks altogether. +This is cost-effective because a single cell phone tower can provide service to +hundreds of customers. + +According to the Egyptian Ministry for Communications and Information +Technology, there were 29.84 million internet users in Egypt in +2016~\cite{egypt-internet-users}, +or about 37.8\% of the population. That number breaks down into 28.65 million +mobile internet subscribers and 4.6 million ADSL subscribers (the primary +wired broadband technology in Egypt), with some presumable overlap between +mobile and wired broadband users. The story is similar in other parts of the less developed world. + +Mobile internet access has some unique challenges beyond the existing +challenges that users of wired internet face. These generally relate to the +variability of available bandwidth and delay. + +Performance issues encountered in access networks are usually related to +bandwidth, latency (the delay between when a data packet is sent and +when it is received), data packet loss, and variations in the delays between +data packets (jitter). In some cases there may also be issues with out-of-order +delivery of data packets or intermittent connectivity. + +Tor uses the \emph{transmission control protocol} (TCP) for connections from +the Tor client to the guard relay, connections between the relays in the +circuit, and the connection from the exit to the destination. TCP provides both +\emph{congestion control} and \emph{flow control}. Congestion control +mechanisms manage the amount of traffic that enters the network to keep it from +being overloaded. Flow control mechanisms limit the amount of traffic sent to +the amount that the receiver is able to handle. + +Ways to measure the maximum throughput---the rate of successful message +delivery---for a TCP connection over a given access network are well +understood~\cite{rfc6349}, however this is only one part of the Tor circuit. +There are multiple TCP connections in a Tor circuit, which makes measurement +more difficult. Initial work on measuring the performance of Tor from an +end-user perspective is detailed in Section \ref{sec:onionperf}. + +When relays or bridges are under an attack intended to create a denial of +service, bandwidth is reduced, data packet loss rises, and latency and jitter +increase. Until connectivity is completely lost, the Tor protocol and the +pluggable transports used with Tor should ideally be able to degrade gracefully +by adapting to the changing network conditions. + +\section{Improving client performance} + +We plan to improve client performance both for users who have bad network +connections and also to ensure that performance degrades gracefully when the +network is under attack. + +\subsection{End-to-end performance} + +Network characteristics such as latency, bandwidth, data packet loss, and +jitter are highly interrelated. For example, in TCP connections such as those +used by Tor, increased latency can slow the time it takes until TCP allows the +available bandwidth to be fully used. Data packet loss and out-of-order delivery +of data also increase latency, as it increases the time before the software +that receives the data can put it back together correctly. + +Tor has traditionally relied on end-to-end flow control to avoid overloading +clients and servers, but has not had a good solution for controlling +congestion at the Tor relays. There are many locations in a Tor relay where +data must be queued before it can be sent, and this can increase the latency in +the network. These locations include network hardware, operating system +interfaces and the Tor software. + +\subsubsection{Congestion control} + +%In looking to reduce the delays introduced by uncontrolled congestion in Tor, +%researchers have explored alternative classes of congestion and flow control. +%In one example~\cite{pets2011-defenestrator}, leveraging Tor's existing +%end-to-end window-based flow control framework and evaluating the performance +%benefits of using small fixed-size circuit windows, reducing the amount of data +%in flight that may contribute to congestion. In a second +%example~\cite{pets2011-defenestrator}, a dynamic window resizing algorithm that +%uses increases in end-to-end circuit round-trip time as an implicit signal of +%incipient congestion. + +Researchers have explored alternative designs for congestion and flow control +in order to decrease the delays introduced by uncontrolled congestion in Tor. +One example~\cite{pets2011-defenestrator} proposes to restrict the amount of +data that is traveling through the network at any given time to a small, fixed +amount per client. Another idea~\cite{pets2011-defenestrator} is to vary that per-client amount based on observed network performance on the Tor circuit. + +A third example~\cite{pets2011-defenestrator} uses a fresh approach to +congestion and flow control inspired by standard techniques from Asynchronous +Transfer Mode (ATM) networks. Here, Tor relays explicitly inform their +neighbors of how much traffic they can accept before becoming congested. This +reduces unnecessary delays and memory consumption. + +Analysis has shown that the first two approaches offer up to 65\% faster web +page response times relative to Tor's current design. However, they are overly +conservative in the amount of traffic they allow into the network, resulting +in slower download times. In contrast, analysis of experiments with the third +proposal show that web clients experience up to 65\% faster web page responses +and a 32\% decrease in web page download times compared to Tor's current +design---though this proposal removes per-stream (end to end) flow +control, so it can't be deployed without further design work. These +results show that there +is clearly room for improvement, although further +research is needed before we decide what to implement. + +\subsubsection{Improved socket management} + +Congestion does not only occur within Tor relay software or within the networks +that join them together; it can also occur in the operating system that the Tor +software runs on. When the Tor relay software decides to send data on a Tor +circuit, the operating system will sometimes queue the data before it sends it. +Some analysis~\cite{jansen14-kist} has indicated that congestion +occurs almost exclusively inside of the operating system's outgoing queues, +dwarfing delays caused by the Tor software itself. + +This work went on to develop a new algorithm, KIST, to manage which circuit's +data to process at a given time. It exposes the operating system's queues to +the relay software, allowing Tor to choose circuits whose data will be sent +immediately, rather than being queued by the operating system. That is, +when the operating system tells the Tor software that many sockets are +writeable, but most of those sockets secretly already have a lot of +data queued inside the operating system, it is not possible for the Tor +software to make good queuing choices. + +KIST reduced +circuit congestion by over 30\%, reduced network latency by 18\%, and increased +network throughput by nearly 10\% in experiments. This improved algorithm has +been included in the Tor relay software since version 0.3.2. + + +\subsection{Resumable uploads} + +Some users may have access networks that provide intermittent connectivity. +This can occur even with good infrastructure when, for example, a user switches +between their cellular data connection and a local Wi-Fi connection. For web +browsing, where many small requests (for web pages, for example) are made, this +sort of dropped connectivity may be noticeable, but recovery happens relatively +quickly. However, if a user is half way through uploading a large file and the +connection drops, it can be very irritating. For users under duress, the +situation may be more serious. They may have a limited timeframe during which +they can upload a file and having to begin all over again may prevent them from +doing it. + +JavaScript libraries, such as +Resumable.js~\cite{resumable-js}, which uses the HTML 5 +File API~\cite{fileapi}, provide resumable upload functionality for web +applications to help address this problem. In the future, a helper function +could be added to Tor Browser to assist in resuming large uploads or downloads +in the event that connectivity is interrupted. If transfers resume +automatically this may even be transparent to the user. + +\subsection{Striping connections} + +Bridges providing access to the Tor network via pluggable transports often have +lower bandwidth available than regular relays. To help in load-balancing across +available bridges and avoid wasting capacity, and also to improve end-user +performance, user traffic can be split across multiple bridges. +Conflux~\cite{pets13-splitting} is one such approach to dynamic +traffic-splitting that assigns traffic to a Tor circuit based on its measured +latency. + +Experiments have shown an improvement of approximately 30\% in expected +download time for web browsers that use multiple Tor bridges and for +streaming video applications. +% ^ what does this mean? XXX +This method introduces tradeoffs between users' +anonymity and performance. As with congestion control however, there is +clearly room for improvement. Further research is needed to decide on a path +forward. diff --git a/2018/sponsor19/report1/task10/MobileBroadbandInternetPenetrationWorldMap2012.png b/2018/sponsor19/report1/task10/MobileBroadbandInternetPenetrationWorldMap2012.png new file mode 100644 index 0000000..7cec5b8 Binary files /dev/null and b/2018/sponsor19/report1/task10/MobileBroadbandInternetPenetrationWorldMap2012.png differ diff --git a/2018/sponsor19/report1/task10c.tex b/2018/sponsor19/report1/task10c.tex new file mode 100644 index 0000000..c1d8cf8 --- /dev/null +++ b/2018/sponsor19/report1/task10c.tex @@ -0,0 +1,131 @@ +\section{Performance while under attack} +\label{perf-dos-attacks} + +There are several ways to mount a Denial of Service (DoS) attack against the +Tor network. This section is an overview of the range of possible ways the +network could be attacked to cause resource exhaustion. + +The following is heavily inspired by the 2015 Tor technical report +``Denial-of-service attacks in Tor: Taxonomy and +defenses''~\cite{dos-techreport}. Section~\ref{dos} describes some recent +attacks on the Tor network. + +\subsection{Types of DoS attacks} + +\subsubsection{CPU consumption} + +Most of Tor's running time is spent performing expensive cryptographic +computation. It requires a lot of processing power on the CPU (central +processing unit---the computer's main processor) to accomplish these tasks. If +an attacker can cause relays or clients to use a lot of processing power on +other things, it could render Tor unable to accomplish its real tasks. + +\textbf{Countermeasures}: + +\begin{itemize} + \item Use more efficient cryptographic algorithms. + \item Rewrite parts of the software so that more tasks can run on multiple + processors at a time. + \item Modify our protocols to be more resistant to attacks that use up + processing power. + \item Improve the code that schedules data to be sent from relays so that one + user's traffic is less likely to interfere with another's. + \item Instrument the code so that we can better detect abnormal patterns of + processor use. + \end{itemize} + +\subsubsection{Memory consumption} + +Tor relies on having adequate computer memory available to function well. +Exhausting the available memory on a server running a relay leads to +performance degradation and sometimes crashes. + +\textbf{Countermeasures.} There are +many places in the Tor code that could benefit from memory optimization: using +smaller objects in memory, cleaning up more frequently, optimizing access to +shared or common data, and so on. + +\subsubsection{Disk space consumption} + +These days, we rarely see servers\textemdash or even +clients\textemdash with very low disk space, but disk space is still very +relevant for certain parts of Tor. For example, directory authorities store +various data about all of the relays in the network on disk and use it to +create the Tor consensus. + +\textbf{Countermeasures.} Detect and respond to low disk space events. Tor may +not be the cause of available disk space becoming low, but it is important that +we ensure that Tor can keep running, even with no available space at all. + +\subsubsection{Bandwidth consumption} + +Attacks that disrupt Tor's ability to move data between the client, the relays +in a circuit, and a destination by consuming a lot of bandwidth are +dangerous and when combined with other attacks can lead to +de-anonymization~\cite{torta05,congestion-longpaths}. + +The simple version of this attack is expensive to mount because it requires +the amount of bandwidth that the attacker is trying to consume on the +target. This could be enough to interfere with one relay or many relays. + +However, there are amplification attacks that, at very low cost, can +force the target relay to use more bandwidth than the attacker expends. +These are rare, but high-impact~\cite{jansen2014sniper}. + +\textbf{Countermeasures:} + +\begin{itemize} + + \item Implement better cell scheduling. We currently use the KIST + scheduler, which is better than the earlier simple round-robin design, + but KIST aims to work well under normal conditions, and a scheduling + approach that remains robust to intentional congestion remains an + open research problem. + + \item Improve our bandwidth measurement system. There is currently work + underway to replace our old, poorly maintained bandwidth scanner, + TorFlow~\cite{mikeperry-hotpets09}, + with a new Simple Bandwidth Scanner (SBWS)~\cite{sbws}. + PeerFlow~\cite{peerflow-popets17}, a system proposed in the academic + literature, is a possibility for the future. + + \item Create a new Tor circuit and migrate a client's traffic to it if + performance on the old circuit is poor. + + \item Optimize the onion services protocol to avoid bandwidth consumption + attacks. Proposal~255~\cite{prop-255}, which would allow load balancing an + onion service across a pool of servers, is one possibility. + +\end{itemize} + +\subsubsection{Network resources exhaustion} + +TCP connections are specified with a port and IP address. There are 65535 +available ports. If an attacker opens, and keeps open, connections to most or +all of the ports on a relay, it will become unusable. + +\textbf{Countermeasures.} We currently have denial of service countermeasures +in place in the Tor relay software that aim to prevent such an attack. +% XXX yeah? what are they? + +We could also explore using UDP, another transport protocol that doesn't suffer from this potential problem. + +It might also be possible to use IPv6, which has a much larger range of +addresses, to mitigate this problem. + +\subsection{Future directions} + +To improve Tor's resilience against Denial of Service attacks, we should favor +defenses that address multiple types of attacks simultaneously over defenses +that simply address one at a time. + +Therefore, we should look for general solutions and process improvements, +rather than piecemeal responses to individual attacks as they are discovered. + +The technical report cited at the beginning of this section lists a series of +recommendations that are still relevant today. However, it's worth highlighting +one strategy in particular that has increasingly become the focus of +our development work in the past year or so: modularity. Rewriting the +Tor code to separate different +functionality into different modules will allow much finer grained control of +how resources are used. It will also help prevent interference between modules. diff --git a/2018/sponsor19/report1/task11.tex b/2018/sponsor19/report1/task11.tex new file mode 100644 index 0000000..9f2e04c --- /dev/null +++ b/2018/sponsor19/report1/task11.tex @@ -0,0 +1,653 @@ +Ongoing, robust network measurement is essential +in order to respond to censorship events, to adapt Tor Browser and other apps to +respond to changing network conditions, and to validate changes to the +Tor network software. + +Section~\ref{sec:public-datasets} describes the information that the Tor Metrics +team collects about Tor users and the Tor network; +Section~\ref{censorship-of-tor} describes information that the Open Observatory +of Network Interference (OONI)~\cite{ooni-paper} and the Tor Networks team collect about censorship of the Tor network. + +\section{Tor Metrics public datasets} +\label{sec:public-datasets} + +Tor Metrics \cite{wecsr10measuring-tor} archives historical data about the Tor +ecosystem, collects data from the public Tor network and related services, and +helps develop novel approaches to safe, privacy preserving data collection. + +Tor relays and bridges collect aggregated statistics about the bandwidth they +use and the numbers of connecting clients per country. The relays protect user +privacy by discarding IP addresses and only reporting country information from +a local database that maps IP address ranges to countries. The relays aggregate +these statistics and send them to the directory authorities periodically. + +CollecTor~\cite{collector} +archives the latest server descriptors, ``extra info'' descriptors containing the +aggregated statistics, and consensus documents from the directory authorities. +This archive is public, and researchers can use the metrics-lib Java +library~\cite{metrics-lib} +to perform analysis of the data. + +In order to provide easy access to visualizations of the archived historical +data, the Tor Metrics website~\cite{tor-metrics} +contains a number of customizable plots to show user, traffic, relay, bridge, +and application download statistics over a requested time period for a +particular country. + +\subsection{Relay and bridge user counts} + +The number of Tor users is one of our most important statistics. It is vital +to know how many people use the Tor network on a daily basis, whether +they connect via relays or bridges, from which countries they connect, what +protocols (transports) they use, and whether they connect via IPv4 or IPv6. + +Because Tor is an anonymity network, we cannot collect +identifying data to learn the number of users. So we don't actually +count users, but rather requests to the directories or bridges that clients +make to update their list of relays in the network. We estimate user +numbers from this information. + +The result is an average number of concurrent users, estimated from data +collected over a day, but not how many distinct users there are. It is not +possible to know whether the same set of users stays connected over the whole +day, or if that set leaves after a few hours and a new set of users arrives. +However, our main interest is finding out if usage changes, so it is not +critical to estimate absolute user numbers. + +Relay users are users that connect directly to a relay in order to connect to +the Tor network; bridge users connect to a bridge as an entry point into the +Tor network. + +\subsection{Safe counting and PrivCount} + +Recent advances in privacy-preserving metrics collection such as private +set-union cardinality~\cite{psc-ccs2017} and PrivCount~\cite{privcount-ccs2016} +can help to improve our user metrics. + +Private set-union cardinality is useful in many settings. It can determine how +many unique users are using Tor, how many unique users connect via a particular +version of client software, and how many unique destinations are contacted. It +could also be used to determine how users regularly connect to the network +(\eg over mobile connections, through proxies, etc.) and how the network is +used (\eg the length of time that users spend on the network in a single +session). + +PrivCount implements a privacy-preserving scheme for distributed measurement +using secure multiparty computation. It provides a method of collecting +network-wide aggregate statistics without revealing the totals provided by each +individual relay. By adding carefully calculated noise, this scheme can also +provide differential privacy guarantees. + +Very recent work~\cite{tor-usage-priv-measurement-imc18} has enhanced PrivCount +and Private set-union cardinality and used them to measure numbers of Tor +users. The results show a much higher number of users than we have +previously estimated: closer to eight million daily users rather than the +early count of two million daily users. +We need to closely examine the methodologies used in this work to validate its +findings. + +\subsection{Reliable geolocation} + +In producing metrics relating to countries, for example the top countries +by daily users shown in Table~\ref{tbl:top-user-countries}, Tor Metrics +uses IP geolocation databases. We currently use the MaxMind GeoLite2 City +database~\cite{max-mind-geolite2}, but a strong reliance on a single source of this data is undesirable. +For calculating metrics relating to relays---where IP addresses are +already public---we also look up autonomous system (AS) information in +these databases to better understand the diversity of the network (as discussed +further in Section~\ref{sec:network-health}). + +\begin{table} +\begin{center} +\begin{tabular}{ | l | l | } +\hline +\textbf{Country} & \textbf{Mean daily users} \\ +\hline +\hline +United States & 367814 (17.70 \%) \\ +\hline +United Arab Emirates & 257893 (12.41 \%) \\ +\hline +Russia & 244418 (11.76 \%) \\ +\hline +Germany & 153335 (7.38 \%) \\ +\hline +France & 105256 (5.06 \%) \\ +\hline +Indonesia & 95731 (4.61 \%) \\ +\hline +Ukraine & 77508 (3.73 \%) \\ +\hline +United Kingdom & 62134 (2.99 \%) \\ +\hline +India & 45891 (2.21 \%) \\ +\hline +Netherlands & 42741 (2.06 \%) \\ +\hline +\end{tabular} +\end{center} +\caption{The top-10 countries by estimated number of directly-connecting +clients between the 17th July and the 15th October 2018. These numbers are +derived from directory requests counted on directory authorities and mirrors. +Relays resolve client IP addresses to country codes locally using an +IP geolocation database.} +\label{tbl:top-user-countries} \end{table} + +One alternative for country code lookups is to use a database from +IP2Location~\cite{ip2location}. We have not yet +explored the benefits of making this change and would be unlikely to be able to +distribute this database as we currently do with the MaxMind database. +% ^ why not? XXX + +One alternative for AS number resolution is RIPEstat~\cite{ripe-stat} which +uses BGP feeds to provide near-live information. In a comparison study by Tor +Metrics on the 1st July 2018~\cite{tor-metrics-geo-study}, there were 269 +relays where there was disagreement between RIPEstat and the latest MaxMind +database and 7889 in agreement ($\kappa = 0.979$ excluding relays for which +either MaxMind or RIPEstat had no AS number). There were 101 relays for which +MaxMind did not return an AS number and 2 relays for which RIPEstat did not +return an AS number. + +The MaxMind database is distributed to users as part of the Tor software, and +it can be used for example to +disable or prefer the use of exit relays in specific countries. So it may be +dangerous for users if they get mixed information about the autonomous system +numbers or country codes assigned to relays. It may be equally dangerous to +incorrectly assign country codes, but without ground truth to compare to, it is +not possible to say whether a switch would improve this situation or not. + +We hope to analyze the different databases and feeds available +to us to determine which options best fit our requirements. + +\subsection{Network performance} +\label{sec:onionperf} + +The performance that Tor users experience depends on many factors and is +the subject of current research. In order to evaluate progress in improving +Tor's performance, we need to continuously measure how fast Tor really is for +our users. + +In June 2009 we began longitudinal measurements of Tor performance using the +Torperf~\cite{torperf} tool. It used a +Tor client with the same path selection algorithms as an ordinary user would +use and performed downloads of a 50~KB file, a 1~MB file, and a 5~MB file. The +initial findings from these measurements~\cite{tor-2009-09-001} and the +ongoing measurements, visualized in Figure~\ref{fig:torperf}, provided a +feedback loop for developers and those looking after the network to understand +the effects that changes could have for the key performance characteristics: +throughput and latency. + +\begin{figure} +\begin{center} +\includegraphics[width=0.8\textwidth]{task11b/torperf-public-2009-06-10-2017-05-01-torperf-5mb.png} +\end{center} +\caption{Overall performance when downloading a 5 MB static file over Tor from +a server on the public internet between July 2009 and April 2017. The graph +shows the range of measurements from first to third quartile, and highlights +the median. The slowest and fastest quarter of measurements are omitted from +the graph.} +\label{fig:torperf} +\end{figure} + +OnionPerf~\cite{onionperf} is a modern +rewrite of Torperf that includes more fine-grained detail in the measurements. +OnionPerf has the ability to measure the performance of onion services from a +user perspective in addition to the traditional measurement using a server on +the public Internet. In April 2017, Tor Metrics began using OnionPerf to +perform measurements of the Tor network, replacing Torperf. We currently +convert OnionPerf's output to a format compatible with Torperf, so Tor +Metrics does not yet handle all the new data that is captured. + +We have, however, introduced new latency visualizations to the Tor +Metrics website using OnionPerf data. For web browsing and other +interactive applications, latency can be as important as throughput in +improving the quality of end-user experience. +Figure~\ref{fig:onionperf-latencies} shows the average latencies measured +for circuits +since Tor Metrics began running OnionPerf. + +\begin{figure} +\begin{center} +\includegraphics[width=0.8\textwidth]{task11b/onionperf-latencies-2017-04-15-2018-10-12-all.png} +\end{center} +\caption{Round-trip latencies of circuits used for downloading static files of +different sizes over Tor, either from a server on the public internet or from a +version 2 onion server. Round-trip latencies are measured as the time between +sending the HTTP request and receiving the HTTP response header. The graph +shows the range of measurements from first to third quartile, and highlights +the median. The slowest and fastest quarter of measurements are omitted from +the graph.} +\label{fig:onionperf-latencies} +\end{figure} + +The Tor Metrics OnionPerf measurements are currently performed using vantage +points in 3 data centers of a single network operator. In the future it is +important that these vantage points are diversified to enable a view of the +network that is closer to that of a real user. More realistic vantage +points could include residential (DSL or DOCSIS) or cellular (3G or LTE) +access networks. +Further, to understand the performance for users in denied countries, +performance measurements should be carried out using pluggable transports. + +\section{Detecting censorship of Tor} +\label{censorship-of-tor} + +The Tor network offers online anonymity, privacy, and censorship circumvention. +Human rights defenders rely on the Tor network to secure their communications, +circumvent the blocking of social media apps during protests, and to securely +report on corruption and other abuses of power. As a result, the Tor network +has become a target of censorship by several governments around the world. In +such countries, users can circumvent the blocking and connect to the Tor +network through the use of bridges. In some cases though, bridges are +blocked too. + +The Open Observatory of Network Interference (OONI)~\cite{ooni-paper} performs +active measurement to detect censorship. Through the Tor Metrics described in +the previous section, we track the expanding usage of Tor and Tor bridges +globally. These metrics allow us to infer when access to the Tor network is +blocked, particularly when we see spikes in Tor bridge usage. In addition to +our measurement projects, we also receive alerts on Tor blocking from our +community members. + +In most countries around the world, the Tor network appears to be accessible. +In recent years, however, we have (mainly) observed the blocking of the Tor +network in the following countries: Egypt, Ethiopia, China, Iran, Turkey, +and Venezuela. + +\subsection{Open Observatory of Network Interference} +\label{ooni} + +Over the last several years, we have been monitoring the blocking of the Tor +network through our censorship measurement software, OONI +Probe~\cite{ooni-probe}, which includes +tests~\cite{ooni-nettest} designed to measure +the reachability of the Tor network and of Tor bridges from the vantage point +of the user. Every month, hundreds of thousands of measurements are collected +and published~\cite{ooni-explorer} from +thousands of networks in more than 200 +countries~\cite{ooni-stats}. These measurements enable +us to track the blocking of the Tor network around the world. + +The ``vanilla Tor" test built in to OONI Probe is the primary means of +detecting censorship of the Tor network. The vanilla Tor test attempts to make +a connection to the Tor network. If the test successfully establishes a +connection within a predefined number of seconds (300 by default), then Tor is +considered to be reachable from the vantage point of the user. But if the test +does not manage to establish a connection, then the Tor network is likely +blocked within the tested network. This test was central to the analyses in the +upcoming sections. + +There is also a ``Tor Bridge Reachability" test that examines whether Tor +bridges work in tested networks. This test runs Tor with a list of bridges and +if it's able to connect to them successfully, we conclude that Tor bridges are +not blocked in the tested network. If the test, however, is unable to make +a connection, then the Tor bridges are either offline or blocked. + +OONI Probe requires volunteers to run measurements and those volunteers must be +located in the target countries. To engage volunteers, OONI has established a +Partnership +Program~\cite{ooni-partner-prog} +to collaborate with local digital rights organizations on censorship +measurement research. Over the last several years, OONI has established 25 +partnerships, many of which involve digital rights organizations in countries +where Tor is blocked, such as Egypt and Iran. We will continue to expand our +community engagement activities to monitor the blocking of Tor and to make it +more resilient to censorship. + +\subsubsection{Egypt} + +Following the blocking of hundreds of media +websites~\cite{ooni-egypt-summary}, +over the last year, more and more Egyptians began to use censorship circumvention technologies. Egyptian ISPs then started blocking numerous circumvention +tools, including the Tor network. + +Last July, OONI +published a research +report~\cite{ooni-egypt-report} +documenting Tor blocking. This study includes an analysis of all network +measurements~\cite{ooni-explorer-egypt} collected from Egypt between January 2017 to May 2018. These +measurements suggest that access to the Tor network was blocked, since the +tests weren't able to make connections to the Tor network within 300 +seconds. More than 460 measurements showed that connections to the Tor network +consistently failed, strongly suggesting that access to it was blocked. + +Tor bridges appear to be blocked by some ISPs in Egypt as well. Vodafone, in +particular, appears to be blocking the default \textit{obfs4} bridges that +are shipped as part of Tor +Browser. (Anecdotally, we hear reports that private obfs4 bridges still work, +but we don't have OONI test results to confirm this conclusion.) +All measurements collected from +state-owned Telecom Egypt, on the other hand, show that the built-in +\textit{obfs4} bridges work. + +This is not the first time that we have observed Tor censorship in Egypt. In +2016, when Egyptian ISPs started to block media sites, we found that the Tor +connection process was being disrupted via the blocking of requests to directory +authorities. + +Figure~\ref{fig:vanilla-tor-eg} illustrates the total number of tests +that successfully connected to the Tor network versus those that failed between +June 2017 and November 2017 from seven distinct autonomous system numbers +(ASNs) in Egypt. 211 tests failed and only 38 test succeeded in +connecting to the Tor network. + +\begin{figure} +\begin{center} +\includegraphics[width=0.5\textwidth]{task11a/eg-success-failure.png} +\end{center} +\caption{Success and failure rates for vanilla Tor measurements performed by +OONI Probe in Egypt between June and November 2017.} +\label{fig:vanilla-tor-eg} +\end{figure} + +Recent OONI measurements suggest that access to the Tor network, when +not using a private obfs4 bridge, remains blocked in Egypt. + +\subsubsection{Ethiopia} + +During a wave of protests in +2016~\cite{bbc-ethiopia-protests}, numerous +Ethiopian media outlets and political opposition websites +were blocked. +WhatsApp was censored as well, along with several circumvention tool sites, +including the Tor website. + +In collaboration with Amnesty International, we published a research +report~\cite{ooni-ethiopia} +documenting these censorship events based on the analysis of OONI network +measurements collected from Ethiopia. While we found that access to our site +(torproject.org) was blocked, we did not find the Tor software itself being +blocked in Ethiopia during the testing period. To enable Tor usage (despite our +site being blocked), we shared information on how to download Tor Browser from +an alternative site~\cite{gettor}. + +Over the last year, however, access to the Tor network has been blocked as +well. Most OONI measurements collected from Ethiopia~\cite{ooni-explorer-ethiopia} in 2017 show that attempts +to establish connections to the Tor network were unsuccessful, strongly +suggesting that access is blocked. + +Under a new Prime +Minister~\cite{ethiopia-new-pm} +who is from the Oromia region\textemdash which has been +protesting~\cite{bbc-ethiopia-protests} +against marginalization and persecution by authorities over the last few years\textemdash +many reforms have taken place in Ethiopia over the past several months. These +include the unblocking of hundreds of websites, which OONI +reported\cite{ooni-ethiopia-unblock} +on in June. + +Access to the Tor Project website, however, remains blocked. Similarly, the +most recent measurements suggest that access to the Tor network remains blocked +as well. Bridge reachability tests have never been run in Ethiopia, and so it +remains unclear if access to Tor bridges is blocked. + +\subsubsection{China} + +China is known for its pervasive internet censorship apparatus, which also +involves the blocking of numerous circumvention tools. Most OONI +measurements~\cite{ooni-explorer-china} +collected from local vantage points strongly suggest that access to the Tor +network is blocked, since most tests fail to establish connections. Between +June 2017 to November 2017, most measurements were unsuccessful, as seen +in Figure~\ref{fig:vanilla-tor-cn}. + +\begin{figure} +\begin{center} +\includegraphics[width=0.5\textwidth]{task11a/cn-success-failure.png} +\end{center} +\caption{Success and failure rates for vanilla Tor measurements performed by +OONI Probe in China between June and November 2017.} +\label{fig:vanilla-tor-cn} +\end{figure} + +In recent months, Tor reachability has been tested across multiple networks in +China. Table~\ref{tbl:vanilla-tor-cn} summarizes the findings from recent +measurements by autonomous system. + +\begin{table} +\begin{tabular}{ | l | l | } +\hline +\textbf{Autonomous System} & \textbf{Vanilla Tor measurement result} \\ +\hline +\hline +Shanghai Mobile Communications (AS 24400) & Failure \\ +\hline +China Telecom (AS 4812) & Success \\ +\hline +Guangdong Mobile Communications (AS 9808) & Failure \\ +\hline +China Education \& Research Network Center (AS 4538) & Success \\ +\hline +China Unicom (AS 4808) & Failure \\ +\hline +China Telecom Backbone (AS 4134) & Failure \\ +\hline +China Mobile Communications (AS 56040) & Failure \\ +\hline +\end{tabular} +\caption{Recent OONI Probe vanilla Tor measurement results by autonomous system +for Chinese networks} +\label{tbl:vanilla-tor-cn} +\end{table} + +Access to the Tor network appears to be blocked in most networks, since almost +all measurements from those ASNs consistently fail to +establish connections. It's worth noting, though, that the Tor network appears +to be accessible from some Chinese networks, such as China Telecom (AS 4812) and +the China Education \& Research Network Center (AS 4538). Bridge reachability +tests haven't been run in China in recent years, limiting our ability to +evaluate whether they work locally or not. + +\subsubsection{Iran} + +The breadth and depth of internet censorship in Iran is pervasive. Thousands of +OONI Probe +measurements~\cite{ooni-explorer-iran} +collected from 60 local networks in Iran over the last several years confirm the +blocking~\cite{ooni-iran-report} +of more than 800 domains. These include media outlets, opposition sites, +pro-democracy sites, human rights sites, the blogs of Iranian political +activists, as well as numerous circumvention tool sites, including +torproject.org. + +We also found the Tor network to be blocked in many networks in Iran, but +accessible in some. While the domain of Tor's bridge database site was blocked +(being a sub-domain of torproject.org), we found that some Tor bridges work in +some networks in Iran. + +Recent OONI measurements suggest that Tor remains blocked in some networks, +like IranCell (AS 44244), but is accessible in other networks, like Aria Shatel +(AS 31549). In general, internet censorship in Iran does not appear to be +deterministic, as we've observed the dynamic blocking and unblocking of +services over time. Censorship measurement is therefore required on an ongoing +basis. + +\subsubsection{Turkey} + +Direct connections to +the Tor network appear to be blocked in Turkey as well. Between June 2017 and +November 2017, most tests attempting to establish connections to the Tor +network failed, as can be seen in Figure~\ref{fig:vanilla-tor-tr}, based on +measurements~\cite{ooni-explorer-turkey} +collected from six distinct ASNs in Turkey. + +\begin{figure} +\begin{center} +\includegraphics[width=0.5\textwidth]{task11a/tr-success-failure.png} +\end{center} +\caption{Success and failure rates for vanilla Tor measurements performed by +OONI Probe in Turkey between June and November 2017.} +\label{fig:vanilla-tor-tr} +\end{figure} + +Recent measurements collected from TurkNet (AS 12735) show that the Tor network +is accessible, while measurements collected from Tellcom Iletisim (AS 34984) +indicate that it's blocked, since most tests failed to establish connections to +the Tor network. This ISP also appears to be blocking access to Tor's website, but the site is accessible from other networks, such as +Vodafone (AS 15897). Bridge reachability tests have never been run by volunteers +in Turkey, limiting our ability to assess whether Tor bridges work locally. + +\subsubsection{Venezuela} + +A few months ago, one ISP in +Venezuela blocked access to the Tor network as well. +Following months of increased censorship, particularly targeting a number of +local media websites and currency exchange sites, state-owned CANTV (AS 8048) +blocked access to the Tor network, possibly to prevent people from getting around censorship~\cite{ooni-venezuela-report}. + +All OONI measurements~\cite{ooni-explorer-venezuela} collected from Venezuela up until 6th June 2018 were +successful, showing that the Tor network was accessible then. On 20th +June 2018, however, Tor testing on CANTV started to fail. Most other +measurements collected from 20th June 2018 onwards (collected from the same +network on an almost daily basis) failed as well, strongly suggesting that +CANTV blocked access to the Tor network. According to OONI's scans in +mid-August 2018 from CANTV, connections to 74\% of well-known IP address and +port combinations of the Tor network were blocked on the reverse path. + +A large number of obfs4 bridges were blocked as well. Bridge reachability tests +run from CANTV in late June 2018 show a failure rate of around 94\% to known Tor +bridges. Not all of these failures are necessarily caused by blocking, as some +bridges might be offline or unreachable. The high percentage of connection +failures, though, strongly suggests that well-known bridges are being blocked. +Repeated testing in August 2018 also presented a high percentage: 88\% of +running bridges were unreachable from a CANTV vantage point. It's worth noting, +though, that private bridges seemed to work. All testing to private Tor +bridges resulted in successful connections, regardless of the type of bridge. +This includes obfs4 bridges and bridges that don't use pluggable +transports---so we conclude that the blocking was based on IP address, and +not some more sophisticated DPI-based approach. + +Over the last few months, CANTV has unblocked access to the Tor network. Further +testing on 2nd October 2018 revealed that around 97\% of public Tor nodes were +reachable from the vantage point of CANTV. While the precise +date of unblocking is unclear, Tor Metrics data seen in +Figure~\ref{fig:relayusers-ve} suggest that Tor may have been unblocked +on 30th August +2018, since we observe a spike in Tor usage on that day. + +\begin{figure} +\begin{center} +\includegraphics[width=0.8\textwidth]{task11b/userstats-relay-country-ve-2018-07-14-2018-10-10-on.png} +\end{center} +\caption{Number of directly connecting Tor users from Venezuela between 1st May +and 10th October 2018. The darker grey range indicates the expected user +counts. Blue and red spots indicate data points that fell either above or +below the expected range.} +\label{fig:relayusers-ve} +\end{figure} + +The Tor Project website has remained accessible in CANTV (and other +networks) all along, even during the time that direct Tor network connections +and default obfs4 bridges were blocked. + +\subsection{Tor Metrics anomaly detection} + +Tor Metrics has an ``early warning system"~\cite{tor-2011-09-001} to indicate +anomalies in the counts of directly connecting Tor users. The detector is based +on a simple model of the number of users per day, per country. That model is +used to assess whether the number of users we observe is typical, too high, or +too low. In a nutshell, the prediction on any day is based on activity of +previous days, locally as well as worldwide. + +This system is integrated into the Tor Metrics website and can annotate +visualizations with any abnormalities that are detected. When a country +puts new censorship in place this can appear in our user data as an increase in +directly connecting users in that country. As an example, Uganda introduced a +``social media +tax"~\cite{bbc-uganda-social-media-tax} on July +1st 2018. This can be seen in Figure~\ref{fig:relayusers-ug} for that date +as an unexpected rise in users. + +Similarly, when a country introduces censorship of the Tor network this can +appear in our user data as a drop in directly connecting users. Many +networks in Venezuela blocked access to the Tor network between June and +August 2018~\cite{venezuela-blocks-tor} +and the effects of this can be seen in Figure~\ref{fig:relayusers-ve}. + +\begin{figure} +\begin{center} +\includegraphics[width=0.8\textwidth]{task11b/userstats-relay-country-ug-2018-05-01-2018-08-01-on.png} +\end{center} +\caption{Number of directly connecting Tor users from Uganda between 1st May +and 1st August 2018. The darker grey range indicates the expected user counts. +Blue and red spots indicate data points that fell either above or below the +expected range.} +\label{fig:relayusers-ug} +\end{figure} + +Another system~\cite{WrightDF15} developed and maintained by academic researchers, detects ongoing per-country +anomalies in the user counts. It identifies contiguous anomalous periods, +rather than daily spikes or drops, and allows anomalies to be ranked according +to deviation from expected behavior. This system is currently run continuously +and reports daily to a mailing +list~\cite{infolabe} +but is not yet integrated with Tor Metrics. + +\subsection{Events timeline} + +Tor Metrics maintains a +timeline~\cite{tor-metrics-news} of events +that might affect user metrics, to aid in the interpretation of data and +visualizations. This timeline is\textemdash by necessity\textemdash manually +maintained. Where possible each entry in the timeline is accompanied by links +to relevant visualizations, discussions, and news articles. We may create entries in response to reports from users or news outlets, automated anomaly +detection, analysis of data collected by OONI and many other sources. + +Some example entries are shown in Table~\ref{tbl:timeline-examples}. When +viewing visualizations on the Tor Metrics website, relevant entries will be +shown under the graph for some visualizations. + +\begin{table} +\begin{center} +\begin{tabular}{ | l | p{0.5\textwidth} | p{0.2\textwidth} | } +\hline +\textbf{Date} & \textbf{Entry} & \textbf{Links} \\ +\hline +\hline +2018-07-01 to present & A social media tax takes effect in Uganda. The +government pressures ISPs to block VPNs. & User graphs, BBC article, AllAfrica +article \\ +\hline +2018-07-28 to present & Another jump of relay users in Turkey, from 5k to about +30k. & User graphs \\ +\hline +2018-07-29 to 2018-08-08 & Protests over road safety in Dhaka, Bangladesh. +Reports of mobile network throttling and blocking of Facebook. & New York Times +article, Daily Star article \\ +\hline +\end{tabular} +\end{center} +\caption{Selected entries from the Tor Metrics Timeline that can provide +context when interpreting the user count data and visualizations.} +\label{tbl:timeline-examples} +\end{table} + +\subsection{Future directions} + +There is significant work to be done to get us from knowing when access to the +Tor network is blocked, to knowing which pluggable transports work in which +censored countries, to using our censorship measurement data to inform +development of new pluggable transports. We don't currently have data about +whether bridges are blocked in many of the countries we've studied, let alone +which pluggable transports might be blocked. We need to develop more +sophisticated tests than OONI Probe's vanilla Tor and bridge reachability tests +to gather this data. + +The type of testing we need to do may not fit into the OONI model\textemdash +OONI aims to deploy a simple, easy to use tool to its volunteers and some of +the Tor pluggable transports are relatively large and unwieldy. We might need +to explore other ways of deploying our tests and collecting data. For example, +we might release a modified version of Tor Browser that runs through the +included pluggable transports, testing to see if connections succeed, and then +uploading the results. + +OONI might deploy new tests that not only establish a connection to the Tor +network, but also perform some activity, to ensure that the test traffic is +representative of that of a real user. A connection may be allowed to succeed +but then be disconnected shortly after, leaving Tor unusable from a user +perspective with no evidence of this being collected by OONI + +Accurate and widespread measurement is essential for us to be able to respond +to censorship. The data that Tor Metrics and OONI collect gives us some +visibility into both ongoing censorship and discrete censorship events, but we +need to do much more. diff --git a/2018/sponsor19/report1/task11a/cn-success-failure.png b/2018/sponsor19/report1/task11a/cn-success-failure.png new file mode 100644 index 0000000..a1d28d4 Binary files /dev/null and b/2018/sponsor19/report1/task11a/cn-success-failure.png differ diff --git a/2018/sponsor19/report1/task11a/eg-success-failure.png b/2018/sponsor19/report1/task11a/eg-success-failure.png new file mode 100644 index 0000000..037f890 Binary files /dev/null and b/2018/sponsor19/report1/task11a/eg-success-failure.png differ diff --git a/2018/sponsor19/report1/task11a/tr-success-failure.png b/2018/sponsor19/report1/task11a/tr-success-failure.png new file mode 100644 index 0000000..d97ef0e Binary files /dev/null and b/2018/sponsor19/report1/task11a/tr-success-failure.png differ diff --git a/2018/sponsor19/report1/task11a/ve-tor-metrics.png b/2018/sponsor19/report1/task11a/ve-tor-metrics.png new file mode 100644 index 0000000..7ae0b75 Binary files /dev/null and b/2018/sponsor19/report1/task11a/ve-tor-metrics.png differ diff --git a/2018/sponsor19/report1/task11b/onionperf-latencies-2017-04-15-2018-10-12-all.png b/2018/sponsor19/report1/task11b/onionperf-latencies-2017-04-15-2018-10-12-all.png new file mode 100644 index 0000000..51d7906 Binary files /dev/null and b/2018/sponsor19/report1/task11b/onionperf-latencies-2017-04-15-2018-10-12-all.png differ diff --git a/2018/sponsor19/report1/task11b/torperf-public-2009-06-10-2017-05-01-torperf-5mb.png b/2018/sponsor19/report1/task11b/torperf-public-2009-06-10-2017-05-01-torperf-5mb.png new file mode 100644 index 0000000..abcad32 Binary files /dev/null and b/2018/sponsor19/report1/task11b/torperf-public-2009-06-10-2017-05-01-torperf-5mb.png differ diff --git a/2018/sponsor19/report1/task11b/userstats-relay-country-ug-2018-05-01-2018-08-01-on.png b/2018/sponsor19/report1/task11b/userstats-relay-country-ug-2018-05-01-2018-08-01-on.png new file mode 100644 index 0000000..e2396c8 Binary files /dev/null and b/2018/sponsor19/report1/task11b/userstats-relay-country-ug-2018-05-01-2018-08-01-on.png differ diff --git a/2018/sponsor19/report1/task11b/userstats-relay-country-ve-2018-07-14-2018-10-10-on.png b/2018/sponsor19/report1/task11b/userstats-relay-country-ve-2018-07-14-2018-10-10-on.png new file mode 100644 index 0000000..0c2e30d Binary files /dev/null and b/2018/sponsor19/report1/task11b/userstats-relay-country-ve-2018-07-14-2018-10-10-on.png differ diff --git a/2018/sponsor19/report1/task6.tex b/2018/sponsor19/report1/task6.tex new file mode 100644 index 0000000..c9c6aed --- /dev/null +++ b/2018/sponsor19/report1/task6.tex @@ -0,0 +1,451 @@ +\section{Tor network health} +\label{sec:network-health} + +The health of the Tor network is crucial to all of the services Tor provides, +including the ability of users to bypass censorship. This section details +the health of the Tor network in terms of capacity, diversity, and performance. +Section~\ref{health-state} describes the current state of the network, +including some statistics and basic information on network health. + +Section~\ref{health-bad} describes our ongoing fight against +malicious relays and includes our detection methods and our process to remove a +relay from the network. + +\subsection{The state of the network} +\label{health-state} + +\subsubsection{Numbers} + +The Tor network is currently composed of about 6400 relays run by +volunteers around the world. As Figure~\ref{png-network} shows, the +number of relays has been quite steady during 2018. + +\begin{figure} +\begin{center} + \includegraphics[width=0.9\textwidth]{task6/network.png} +\end{center} +\caption{Number of running relays and bridges in the public Tor network. For +relays, only those that have been verified as reachable by the directory +authorities are included. For bridges, only those that announce themselves to +the bridge authority are included (that is, private bridges are not included).} +\label{png-network} +\end{figure} + +This graph includes bridges, which are relays that are not listed in the public +directory. In early July we transitioned to a new bridge authority, which is a +special relay that aggregates bridge information. Currently there are slightly +under 1000 bridges in the network. + +The capacity of the Tor network is hovering around 275 GBit/s and around +125 GBit/s are actually in use. Figure~\ref{png-bw} shows an +increase in available bandwidth since March 2018. + +\begin{figure} +\begin{center} + \includegraphics[width=0.9\textwidth]{task6/bw.png} +\end{center} +\caption{The sum of advertised and consumed bandwidth across all relays +in the network. +The advertised bandwidth is the peak volume of traffic, both incoming +and outgoing, that a relay has observed itself able to do based on +recent data transfers. The consumed bandwidth is the volume +of traffic, both incoming and outgoing, that the relay has reported it has +transferred.} +\label{png-bw} +\end{figure} + +As shown in Figure~\ref{png-user}, by our measurements the network is +currently seeing an estimated 2 million users each day. Since March, +this number has been quite steady. It is important to understand that this +count makes the conservative assumption that each of these users is online +for the entire day. If every user is instead online only a few hours each +day, our estimate could be low by a factor of ten. +Early reports from new +research~\cite{tor-usage-priv-measurement-imc18} show a much higher estimate and +we plan to take a close look at their methodology. + +\begin{figure} +\begin{center} + \includegraphics[width=0.9\textwidth]{task6/user.png} +\end{center} +\caption{Estimated number of daily directly-connecting clients; this +excludes clients connecting via bridges. These estimates come from +counting the number of directory requests reported by relays.} +\label{png-user} +\end{figure} + +Notice the surge in users at the beginning of the year. This was due to a +denial of service attack that we discuss in Section~\ref{dos}. We can +ignore this for now. + +Finally, Figure~\ref{png-user-bridge} shows the number of users using a bridge +to enter the network. The current estimate shows around 55,000 daily users. Again, +disregard the surge of users during the middle of the year; this was also the +result of a denial of service attack. + +\begin{figure} +\begin{center} + \includegraphics[width=0.9\textwidth]{task6/user-bridge.png} +\end{center} +\caption{Estimated number of daily clients connecting via bridges. These +numbers come from the number of directory requests reported by bridges.} +\label{png-user-bridge} +\end{figure} + + +\subsubsection{Diversity} + +Diversity is an important factor for the safety and anonymity provided by the +Tor network. We can measure diversity in a variety of ways, but for this +discussion, we focus on diversity of the operating systems (OSes) that relays +run on and the diversity of the physical locations of relays. + +The following simple example shows the importance of operating system +diversity: a software vulnerability that affects all Windows computers won't +threaten the security of relays that run on Linux. So in terms of security, +having relays that run on a wide variety of OSes improves the resilience and +safety of the Tor network. + +Unfortunately, the vast majority of relays (over 90\%) are currently running on +the Linux OS. The rest are on variants of the BSD OS; very few are on +Windows. This is far from ideal for the network, and there is work to do to +make sure Tor is easy to install and configure on many platforms. One of our +current projects includes outreach and improved documentation to make it easier +to set up relays on BSD OSes. + +Geographic diversity is important because it improves the anonymity the network +can provide, as well as its ability to help bypass censorship. If someone +watching network traffic, such as a government actor, can observe both the +connection to the guard relay and traffic exiting the Tor network, they may be +able to compromise the anonymity of the user. If the guard relay and the exit +relay are in different jurisdictions, there is much less chance of this. + +Also, it is easier to censor a connection if, for example, an ISP can observe +a user connecting to the Tor network as well as the exit relay and determine +the user's web destination. If the exit relay is in a different jurisdiction +than the user, there is less chance that this type of censorship can succeed. +In general, spreading relays across different jurisdictions lessens the chance +that a single observer can see the entire path through the Tor network. + +%Relays concentrated in only a few countries would be very bad for the +%anonymity of the network because it becomes much easier to observe from an +%attacker perspective than if the relays were evenly spread out around the +%world in many more countries that have different geo-political realities. +% +%This is true for entry, middle and exit relays of the network and it is +%critical for the safety of Tor users. +% + +Figure~\ref{png-exit-prob} shows the probability that a Tor +connection will exit the network in each continent. As you can see, there is a +high concentration of exit relays on the European continent. + +\begin{figure} +\begin{center} + \includegraphics[width=0.9\textwidth]{task6/exit-prob.png} +\end{center} +\caption{Exit probability by continent based on resolving relay addresses +using an IP geolocation database.} +\label{png-exit-prob} +\end{figure} + +We use IP geolocation databases to determine where the exit relays are located, +and these are often not completely accurate, but we see that users will almost +always exit the network either in North America or Europe. This is far from +ideal and something we are working to improve. We've recently hired a relay +advocate who helps support current relay operators and does outreach to attract +new ones. In addition, as part of our global south initiative, our community +liaison has been helping volunteers set up relays in those regions. + +\subsection{Malicious relays}\label{health-bad} + +This section describes the types of malicious relays we see in the network and +how we deal with them. + +\subsubsection{Rejecting relays} + +Anyone on the Internet can run a relay which means that we need to be aware +that malicious actors can join anonymously and disrupt the network---sometimes +in ways we haven't imagined. + +The nine Tor directory authorities come to a consensus every hour about which +relays in the network can be used and publish this list. If a majority of +directory authorities agree that a relay is behaving maliciously, it is removed +from the list. + +The Tor community created a \emph{bad relay} team that is in charge of +detecting malicious relays and proposing reject rules to the directory +authorities. The directory authorities, in turn, decide whether to apply the rules so they really have the final word. + +That team has a series of tools to probe the network in order to +detect malicious behavior by relays. Regularly, all of the 6400+ relays +are probed and tested for various things. Here are some of the current tests: + +\begin{itemize} + \item Stripping SSL certificate + \item Re-writing/Redirecting plaintext Web page + \item TLS Downgrade + \item Bitcoin address rewrite + \item Exit re-injecting traffic into the network + \item Malicious onion service directory +\end{itemize} + +There is, of course, much more that we could be doing, and we are always +looking for volunteers to help with this. In an ideal world, the Tor Project +would have funding to hire a \emph{network health engineer} to monitor +the network more closely and +improve our detection methods. + +\subsubsection{Malicious onion service directories} + +A relay +that has been online for 96 hours or more can become an \emph{onion +service directory}. +Because of a design flaw in version 2 of the onion service protocol, +such a relay can learn addresses of onion services in the network. A +long-lived relay can learn many onion addresses over time. + +This could enable the relay to launch a series of attacks in order to +de-anonymize onion service users. We put great effort into +designing version 3 of the protocol, which fixes this problem. But we still, +and will for years to come, have version 2 services running that are affected +by this issue. + +For this reason, we have a scanner that detects onion service directories that +collect .onion addresses and visit them. Every week we reject 5 to 10 relays +from the network that are doing this. + +\subsection{Current outlook and future directions} + +The Tor network is healthy in terms of capacity. +% It is not currently using all +%of the bandwidth available to it and so has room to serve more users. +% ^ no, this isn't right: filling up all the capacity would be essentially +% impossible since any given circuit will have a bottleneck relay in it. +We have a +healthy number of relays that are spread out over many countries around the +world, which is crucial for protecting anonymity and evading censorship. + +The number of Tor users is also important to the health of the system. One +can't be anonymous alone---good anonymity requires a crowd. As the number of +Tor users continues to grow, the anonymity provided by the network becomes +stronger. By working towards making Tor more accessible, more user friendly, +and more widely deployed on different devices (for example mobile), safety is +improved. + +The Tor Project and its community have built tools and processes to monitor, +detect, and reject malicious relays, making the network safer. Onion service +version 3 is a great example of years of cooperation between the development +team, researchers, and our community to improve safety. + +There is, of course, a lot more that we can do. Getting more exit relays +running in more places around the world is an important goal, along with adding +more OS diversity to the network. Improving our network monitoring is an +ongoing goal. The health of the network really depends on collaboration among +everyone in our community. + +\section{Denial of service} +\label{dos} + +This section describes the denial of service attacks that the Tor network +faces. We'll use a recent example to demonstrate how important it is that our +community and monitoring work together. + +\subsection{Notable attacks} +\label{dos-attacks} + +In 2015, Nick Mathewson, Tor maintainer, released a technical report +\cite{dos-techreport} detailing different denial of service attacks on the Tor +network along with possible defenses that could be implemented. See section~\ref{perf-dos-attacks} for highlights from this report. + +Over the years, the Tor Project and community have dealt with many attacks of +this kind, and they usually come as a surprise. This section highlights some of +the attacks we have faced and the lessons they have taught us. + +\subsubsection{Sefnit botnet} + +On the 20th of August 2013, the number of users connected to the network +rose to abnormal levels~\cite{botnet-2013} (see Figure~\ref{dos-sefnit}). +Initial assessments of some relays showed a large number of clients trying to +connect to onion services. + +\begin{figure} + \begin{center} + \includegraphics[width=0.9\textwidth]{task6/sefnit.png} + \end{center} + \caption{Estimated number of users between August 2013 and January 2014.} + \label{dos-sefnit} +\end{figure} + +Although the network was still working fine, relays experienced higher than +normal use of their processors. This was traced to TAP~\cite{tor-spec-tap}, +the protocol for establishing communication that the Tor client used. +NTor~\cite{tor-spec-ntor}, a new, more secure, and better performing protocol, +was about to be released in a new version of the client software. + +Tor developers changed the relay software so that it prioritized the NTor +protocol. Old clients using TAP had less priority and were phased out. + +Fortunately, by the end of 2013, the rise in users was identified by a +Microsoft researcher as part of the Sefnit botnet. It was removed by +Microsoft anti-virus at that point. + +\subsubsection{The sniper attack} + +In February 2014, a paper was presented at the Network and Distributed +Systems Security symposium titled \textbf{The Sniper Attack: Anonymously +Deanonymizing and Disabling the Tor Network}~\cite{jansen2014sniper}. + +It describes a way to remotely make a Tor relay ineffective using very few +resources. One of the most important aspects of this attack is that it can +be used very efficiently to deanonymize users, especially onion service users. + +This is a concrete example of how a very cheap DoS could be used to mount other +types of attacks. The academic literature is years ahead of practice in terms +of attacks, so this is currently theoretical. Until we see it in practice, we +don't know what its actual effects might be. + +The sniper attack showed us that taking down a relay could lead +to deanonymizing specific onion services. + +\subsubsection{DoS attack using onion services} + +In mid December 2017, relay operators started to report to the tor-relays +mailing list that they were seeing spikes in traffic to their relays and +unusual amounts of memory and processing power being used. + +This can sometimes happen in normal circumstances. For example if your relay +becomes the guard relay for the Facebook onion service, you'll see a surge in +resource usage in order to handle all of the users trying to reach it. + +However, by the end of the month, the number of reports was unusually high, +which led us to investigate further. We also noticed that, at the same time, +there was a huge rise in the number of Tor users (see +Figure~\ref{dos-hs-2018}). + +\begin{figure} + \begin{center} + \includegraphics[width=0.9\textwidth]{task6/hs-2018-dos.png} + \end{center} + \caption{Estimated number of daily users between August 2017 and March 2018.} + \label{dos-hs-2018} +\end{figure} + +After days of investigation, we realized that the entire network was being +bombarded by onion service requests. The sheer number was causing relays to +crash, to be shutdown by their operators to conserve resources, or at minimum, +to be rendered very slow or unusable. + +We analyzed connection patterns to some of the affected relays and noticed that +there were 3 types of onion service connections that were coming to the relays +in large numbers: + +\begin{enumerate} + \item Client rendezvous requests + \item Service rendezvous requests + \item Tor2web rendezvous requests +\end{enumerate} + +The attacker created hundreds of thousands of client onion service requests (1) +to specific onion services, which created a large number of rendezvous +circuits (2), making the problem significantly worse. + +We believe the Tor2web requests (3) were unrelated, although they started +around the same time. + +Tor2Web is a gateway that allows users to access onion services from a regular +web browser. This speeds up connections for the user, but does not provide +anonymity. The so called ``DarkWeb scanners" attempt to scan all onion services. +They use Tor2web to increase their efficiency and thus scan the onion space +faster. This causes excessive memory and processing power to be used on the +relays that connect with the onion services. + +In the face of this denial of service attack (DoS) we quickly rolled out 3 +defenses which we implemented in all stable versions of Tor. + +\begin{itemize} + \item Limit concurrent connections + \item Limit the rate at which circuits can be created + \item Block Tor2web connections +\end{itemize} + +We observed that all of the malicious requests were coming from roughly 500-600 +different IP addresses located within the networks of well known hosting +providers. This is probably because the cost of mounting a large DoS attack +from many IP addresses is much higher than only using relatively few addresses. + +Because thousands of requests were coming from the same IP address, limiting +the number of concurrent connections to guard relays from the same address +was an effective defense. In addition, after the limit on concurrent +connections was reached, we limited the rate at which guard relays could +contact other relays to form a circuit through the Tor network. We also blocked +connections from Tor2web. + +%Furthermore, if a certain number of connections on the same IP was reached, the +%circuit creation rate limit defense would kick in and only allow you a +%specific rate and the rest would be denied. These were an attempts at soaking +%up large number of circuits/connections from clients using the same +%connections at the Guard node so it doesn't propagate into the network. + +Once the majority of relays were running the updated software, the performance +of the network recovered quickly. After a few months, the attack stopped. +To this day, these defenses are still in place, protecting the Tor network +from such abuse. + +\subsubsection{Key takeaways} + +These episodes took us by surprise and forced some Tor developers to drop +everything to investigate and work on defenses. But they produced some key +takeaways. + +\begin{itemize} + \item Large numbers of circuit requests create pressure not only on the + network, but also on the Tor software. DoS attacks often highlight weaknesses + in the application that can cause it to become unusable or to crash. + Identifying these weaknesses prior to an attack is crucial to making Tor more + resilient. + + \item The onion service design is clearly susceptible to DoS attacks. We have + begun thinking about how we can solve these problems, but this is ongoing + work. + + \item Listening to the Tor community is critical. Because Tor developers + engage with the relay operators, we were able to notice that an attack was + happening more quickly than if we had relied only on our own measurements. + Working with our community has been instrumental in defending against most of + the attacks we've experienced over the years. + + \item DoS attacks always have unpredictable effects, not only on the network + but on the Tor software itself. These are very dangerous attacks that can + quickly spiral out of control and we take them extremely seriously. + \end{itemize} + +\subsection{The future} \label{dos-future} + +There are several important points to keep in mind when we consider how to +defend against future DoS attacks on the Tor network. + +First, encouraging a wide and healthy research community is crucial. +Researchers often notice possible attacks before they are actually seen in +practice. Reacting to what researchers discover is important to keeping the +network strong. + +Second, we need to interact constantly with our user and relay operator +communities. They have their fingers on the pulse of Tor network health and are +our most efficient ``monitoring device''. When they report issues, it is because +they care about the Tor network. It is our job to listen to and work with them +to improve the safety and performance of the network. + +Third, we need to improve our ability to understand what is going on inside the +Tor software. When we are faced with a potential DoS attack, extracting +relevant information quickly is critical. In order to do this we need proper +instrumentation in the Tor software. We don't currently have this, but in the +future, we need it. + +Finally, we need the resources to defend against attacks. When these attacks +occur, developers need to drop everything to investigate and work on +fixes. The Tor Project needs to get to the point where it is free to work on +what is important for the Tor network and our users. We need to be able to +allocate resources towards defenses without jeopardizing our funding. Without +the ability for developers to take the time necessary to defend against these +attacks, the next one could be the one that takes down the network. diff --git a/2018/sponsor19/report1/task6/bw.png b/2018/sponsor19/report1/task6/bw.png new file mode 100644 index 0000000..0684aeb Binary files /dev/null and b/2018/sponsor19/report1/task6/bw.png differ diff --git a/2018/sponsor19/report1/task6/exit-prob.png b/2018/sponsor19/report1/task6/exit-prob.png new file mode 100644 index 0000000..ee99c5b Binary files /dev/null and b/2018/sponsor19/report1/task6/exit-prob.png differ diff --git a/2018/sponsor19/report1/task6/hs-2018-dos.png b/2018/sponsor19/report1/task6/hs-2018-dos.png new file mode 100644 index 0000000..e0324e4 Binary files /dev/null and b/2018/sponsor19/report1/task6/hs-2018-dos.png differ diff --git a/2018/sponsor19/report1/task6/network.png b/2018/sponsor19/report1/task6/network.png new file mode 100644 index 0000000..8105b8e Binary files /dev/null and b/2018/sponsor19/report1/task6/network.png differ diff --git a/2018/sponsor19/report1/task6/sefnit.png b/2018/sponsor19/report1/task6/sefnit.png new file mode 100644 index 0000000..661bb6f Binary files /dev/null and b/2018/sponsor19/report1/task6/sefnit.png differ diff --git a/2018/sponsor19/report1/task6/user-bridge.png b/2018/sponsor19/report1/task6/user-bridge.png new file mode 100644 index 0000000..06a8773 Binary files /dev/null and b/2018/sponsor19/report1/task6/user-bridge.png differ diff --git a/2018/sponsor19/report1/task6/user.png b/2018/sponsor19/report1/task6/user.png new file mode 100644 index 0000000..a3ca637 Binary files /dev/null and b/2018/sponsor19/report1/task6/user.png differ diff --git a/2018/sponsor19/report1/task7a.tex b/2018/sponsor19/report1/task7a.tex new file mode 100644 index 0000000..7e78c5b --- /dev/null +++ b/2018/sponsor19/report1/task7a.tex @@ -0,0 +1,255 @@ +The Tor network is an open network. Tor directory authorities periodically +publish information on the state of the network, including a list of the +addresses of all of the relays that are available for use. This information +must be available so users can use the network, but its availability +allows various actors, such as ISPs or nation states, to prevent users from +connecting to the Tor network. It also allows service providers (like +websites) to block requests coming \emph{from} the Tor network. + +% Not sure this is relevant. If they can block guards, why does blocking dirauths matter? +%Since Tor users need to be able to connect to the Tor network to +%learn information about the current state of the network from the directory +%subsystem, this becomes an effective way to block access to the Tor network +%from users. + +Tor bridges are Tor relays that are not listed in the public directory. This +makes it hard for censors to block connections to them. Of course, because +we can't publish a list of bridge addresses, we need another way for users that +need them to discover them. + +Using a bridge is often not enough to evade censorship. Some censors use deep +packet inspection (DPI) to prevent people from using Tor. DPI is a technique +that examines data as it moves across the internet and tries to determine what +kind of traffic it is, for example, regular web traffic, encrypted web traffic, +video streaming, or Tor. Pluggable transports try to solve this problem by +disguising the Tor traffic between the user and the bridge so that it doesn't +look like Tor traffic. + +\subsection{Bridge distribution} +\label{bridge-distrib} + +Because bridge addresses are not listed in the public directory of relays, +applications that use Tor need another way to find them. Tor Browser comes +pre-configured with a few dozen bridge addresses that might help in places where Tor +is blocked. But since anyone can download Tor Browser and see the list, censors +can block these bridges along with blocking the publicly listed relays. + +If the bridges that come with Tor Browser don't work, an option for +finding other bridge addresses is \emph{BridgeDB}. Users can access BridgeDB at +https://bridges.torproject.org/ using an ordinary web browser. The user solves +a CAPTCHA and is given some bridge configuration lines, which include the +bridge address. A user can also request bridges via email. This option is useful if a +censor blocks the BridgeDB website. The request must be made from a Yahoo, GMail, +or Riseup email address and sent to\\bridges(a)torproject.org. + +The BridgeDB service partitions the bridges that it gives out, +with the goal of limiting the rate at which attackers can discover +bridges. Specifically, an attacker who wants to enumerate many bridges +needs to interact with the web interface from many different IP addresses +around the internet, and needs to interact with the email interface from +many different email addresses. + +When requesting bridges from BridgeDB, either over the web or by email, a user +can also specify additional information, such as whether they need a specific +pluggable transport or require addresses that work over IPv6. + +There are several drawbacks to the BridgeDB solution: the user has to manually +make the request; the user may not know whether they need a pluggable transport +or an IPv6 address; the user has to manually enter the bridge configuration +lines into a Tor Browser configuration dialog. + +Tor Browser 8.0, released in September of 2018, includes the ability to request +bridge addresses from within the application. More information about the way +Tor Browser helps get around censorship is in Section~\ref{browser-censorship}. + +\subsection{Pluggable transports} +\label{pt-types} + +A pluggable transport is a program that is used between the +user's Tor client, such as Tor Browser, and a Tor bridge. The pluggable +transport's job is to change the appearance of the data that flows between +itself and the bridge so that a censor won't be able to recognize it as Tor +traffic. See Figure~\ref{obfsproxy-diag} for an example. + +\begin{figure} +\begin{center} +\fbox{\includegraphics[width=0.8\textwidth]{task7a/obfsproxy_diagram.png}} +\end{center} +\caption{Pluggable transport example using obfsproxy} +\label{obfsproxy-diag} +\end{figure} + +The pluggable transport API~\cite{tor-pt-spec} enables developers and +research groups to invent pluggable transports that are resistant to different +types of censorship. Then a pluggable transport can be chosen based on the +conditions a user is experiencing in their location. The availability of +\emph{goptlib}, a Go programming language library that takes care of all the +communication between the Tor client and the pluggable transport, has made the +Go language very popular for developing pluggable transports~\cite{goptlib}. + +The following sections describe some pluggable transports that either have been +used by Tor, or that have the potential be used by Tor in the future. + +\subsubsection{Obfsproxy} + +Obfsproxy makes Tor traffic look like a random stream of bytes. This type of +pluggable transport is known as a \emph{look-like-nothing} pluggable transport +and works best when censors have a list of protocols that they try to recognize +and then block. There have been three versions of obfsproxy. + +\textbf{obfs2} + +Obfs2 was the first pluggable transport that the Tor Project developed. +Inspired by the Obfuscated OpenSSH project, obfs2 simply transforms Tor +traffic into a random stream of bytes. It uses a naive protocol for +exchanging encryption keys, which makes it vulnerable to passive attacks that +can reconstruct the keys and then recognize the obfuscation. + +\textbf{obfs3} + +Obfs3 is another older pluggable transport very similar to obfs2. obfs3 uses +Diffie-Hellman, a better key exchange protocol, which makes it immune to passive +attacks that try to deduce the encryption keys. + +\textbf{obfs4} + +All of the pluggable transports before obfs4 were vulnerable to a class of +active attacks called \emph{active probing attacks}. A censor can connect to +a bridge and pretend to be a client using a pluggable transport. If the bridge +replies with pluggable transport traffic, then the censor can tell that it's a +bridge and blocks it immediately. This tactic has been used by China to detect +and block bridges~\cite{greatfirewall-tor}. + +Obfs4 is the first deployed pluggable transport protocol to defend against this +attack. Obfs4 requires that the client prove it knows a secret before the +bridge replies. This means obfs4 can resist active probing attacks. + +Obfs4 is one of the most popular pluggable transports in use today. + +\subsubsection{ScrambleSuit} + +ScrambleSuit, like obfsproxy, is a pluggable transport that makes traffic look +like a random stream of bytes. But ScrambleSuit also changes the lengths of its +data packets, as well as the time between sending them, to confuse censors that +rely on those characteristics to recognize Tor traffic. + +\subsubsection{FTE} + +Format Transforming Encryption (FTE) was one of the first pluggable transports +that did not belong in the look-like-nothing group. Instead, FTE uses an +encryption scheme to make Tor traffic look like regular http web traffic, \ie +it looks like the user is just visiting unencrypted +websites~\cite{fte-usenix14}. + +This type of pluggable transport is useful in the face of a ``whitelisting'' +censor, that is, a censor that has a list of protocols that it recognizes and +allows. + +\subsubsection{Flashproxy} + +Flashproxy~\cite{flashproxy-pets12} is a pluggable transport that allows +censored users to quickly find and use short-lived proxies operated by +volunteers around the globe. The strength of the system is that these proxies +can be operated by a volunteer simply visiting a website---no technical skill +is required. Because the user's Tor client connects to one of these browser +proxies rather than a +Tor bridge, there is no need to find bridge addresses. Flashproxy hides its +traffic within Websocket, a common web protocol. + +A major weakness of Flashproxy is that the vast majority of censored users are +subject to \emph{network address translation} (NAT) which means they can not +accept incoming connections from the internet. While it's fine for the +volunteer flashproxies to be behind NAT (because they make outgoing +connections to both the censored users and the Tor network, to glue them +together), the limitation that the censored users need to be directly +reachable on the internet drastically reduces the usefulness of the design. + +See Section~\ref{pt:snowflake} for a description of Snowflake, an improved +version of Flashproxy that solves this problem. + +\subsubsection{Meek} + +Meek~\cite{meek} is a pluggable transport that uses \emph{domain +fronting}~\cite{domain-fronting} to get around +censorship. In domain fronting, a client makes a connection to an allowed +website and that website redirects the connection to a censored site that is in +the same domain. This technique is generally used within the domains of large +cloud service providers. Meek hides its traffic within encrypted web requests +and responses between it and the allowed website. + +There are two major problems with domain fronting. Cloud providers charge for +all of the traffic that goes into and out of their networks, so it is expensive +to deploy. It also requires the cooperation of the owner of the domain, which +makes it susceptible to political pressure on domain owners. For example, until +April 2018, Amazon and Google supported domain fronting; they disabled it, +reportedly in response to pressure from the Russian +government~\cite{russia-amazon-google}. Currently, the only place where Meek is +deployed is the Microsoft Azure cloud. + +So far, meek has proven resilient to blocking. + +\subsubsection{Marionette} + +Marionette is a fairly new pluggable transport developed by the US company +RedJack. Marionette's design~\cite{marionette} is similar to that of +FTE. Marionette can handle a +relatively large amount of traffic quickly and can be used to make Tor traffic +look like traffic from a variety of different protocols. For now, Marionette +is focused on making Tor traffic look like regular web traffic. + +Marionette is written in Google's Go programming language and uses the +goptlib library. + +Marionette is in the late development stage. The next step is to deploy it to +a set of stable bridges so that we can evaluate it in a variety of censored +locations. + +\subsubsection{Next generation pluggable transport: Snowflake} +\label{pt:snowflake} + +The most promising next generation pluggable transport is +Snowflake~\cite{snowflake}. +Snowflake is similar to Flashproxy in that it does not require the user to find +bridges, and it connects the user's Tor client to a short-lived proxy. Like +Flashproxy, the proxies are run by volunteers visiting a web page. + +Snowflake hides its traffic within the WebRTC protocol---the same protocol that +Google Hangouts uses. The advantage of using WebRTC is that it has the ability +to allow incoming connections to computers using it even if they are subject to +NAT. + +Snowflake is a work in progress. Although we have a working prototype in the +alpha releases of Tor Browser for Linux and Mac OSX, there are challenges to +getting it working on Windows. In addition, there are several outstanding +research questions, including understanding what is missing from the code base, +understanding whether a system like Snowflake does indeed work in denied +countries; understanding barriers to getting pluggable transports like +Snowflake working on Android too, since an increasing percentage of the world +is moving from desktop to mobile. + +The Guardian Project~\cite{guardianproj} currently +has a grant to begin to answer some of these questions in the context of +Android and Orbot. They also hope to work on enabling any Android device, such +as Chromebooks, Android TVs, and other home devices to act as volunteer +Snowflake bridges. + +The Tor Project is in the process of hiring a software developer to +explore some of these questions and to work on other anti-censorship +technologies as well. + +\subsection{Designing new pluggable transports} +\label{pt:design} + +A common anti-censorship strategy is to make it unappealing for censors to +use a certain blocking method because of \emph{collateral +damage}\textemdash allowed content that will also be blocked. For example, domain fronting works because most censors don't want to +block access to large cloud providers. A variation on this theme is to mimic +traffic that is too important to block, such as web traffic or WebRTC traffic. + +In designing new pluggable transports, we need to consider how a censor +might attempt to block them, as well as what collateral damage might result +from that blocking. Adversary +Lab~\cite{adversary-lab} is a service that analyzes captured network traffic to +identify statistical properties. Using this analysis, developers can create +filtering rules to block sampled traffic, and learn how to improve a transport +so that blocking it would maximize collateral damage. diff --git a/2018/sponsor19/report1/task7a/obfsproxy_diagram.png b/2018/sponsor19/report1/task7a/obfsproxy_diagram.png new file mode 100644 index 0000000..4114dae Binary files /dev/null and b/2018/sponsor19/report1/task7a/obfsproxy_diagram.png differ diff --git a/2018/sponsor19/report1/task7b.tex b/2018/sponsor19/report1/task7b.tex new file mode 100644 index 0000000..b277953 --- /dev/null +++ b/2018/sponsor19/report1/task7b.tex @@ -0,0 +1,257 @@ +\subsection{Tor Browser} +\label{browser-censorship} + +In many places in the world, censorship of the web is common. Users are +routinely blocked from connecting to websites by ISPs, governments, corporate +firewalls, and public access points such as internet cafes. Websites are shut +down, logs of users' connections are seized, and users can be punished for +their individual browsing history. + +Tor Browser is designed to combat this systemic assault on the rights of +individuals. Uniquely among all available web browsers, Tor Browser empowers +millions of users around the world to bypass censorship and read any website +they want, without interference. + +Since the project began in 2008, as the Tor Browser Bundle, Tor Browser has +evolved from a bundle of related projects into a clean, streamlined, and usable +web browser. At its core, Tor Browser is a modified version of Mozilla Firefox, +providing more privacy protections than the standard +browser~\cite{tor-browser-design}. Fortunately, with Mozilla's support, many of +the modifications written for Tor Browser are now also integrated into Firefox~\cite{tor-uplift}. + +Sometimes censors attempt to prevent users from downloading and installing Tor +Browser by blocking access to the Tor website. Our GetTor service provides a +way for users to get Tor Browser from another site. GetTor was developed by an +intern participating in Google's Summer of Code. Due to resource constraints, +it is not currently maintained and does not automatically check for new +versions of Tor Browser and so sometimes delivers out of date versions. An +auto-update mechanism is planned that will ensure that users who contact the +service will always get the latest version of Tor Browser. + +Tor Browser 8.0 provides a new feature called \emph{moat} to make it easy for +a user to request bridge addresses from within the application. Moat presents the user with a CAPTCHA to solve, then Tor Browser receives +additional, unpublished, bridge addresses over a secure encrypted connection. +Tor Browser automatically configures itself to use the new bridge addresses. + +The bridges Tor Browser provides use pluggable transports to evade blocking +based on deep packet inspection. The pluggable transports currently used are +obfs4, FTE, meek (through the Microsoft Azure cloud), and obfs3. For +descriptions of the +types of pluggable transports see Section~\ref{pt-types}. + +Although using tools to get around censorship currently requires some level of +technical knowledge, we have made improvements to help users connect to +the internet from censored locations. We have been working with local +speakers of non-English languages to find metaphors that can help explain +complex concepts. As a result of this user-focused effort, Tor Browser is now +available in 25 languages. For more information about our international user +testing for Tor Browser 8.0, see Section~\ref{ux-testing-outreach}. + +We are doing ongoing work to make it easier for users to bypass censorship. We +are in the planning stages for a much simpler interface to provide fully +automated bridge setup for users behind national firewalls. We expect this work +to make anti-censorship technologies much more widely accessible to users. + +Measures within Tor browser that keep people safe are often especially relevant +to users under censorship. Our reproducible build process makes it so that +anyone can (and should!) verify that the software we release is based on the +source code we say it is. An independent party can take our source code and the +specifications for our build environment and build Tor Browser. All of the +resulting packages should be identical, byte for byte, to the software we +release. This is an important way to verify the integrity of our software and +thus increase user safety. + +Another feature that enhances user safety is the domain isolation feature (this +is sometimes referred to as ``first party isolation''). Browser tabs that are +connected to one internet domain run in a separate environment from tabs +connected to another domain. Each domain has its own circuit through the Tor +network, and cookies and other trackers from each domain are stored separately +from those of other domains. These separate environments make it difficult for +websites or tracking networks to link activity between domains. This means that +it is safe, for example, to be logged into Facebook in one tab and to post +anonymously to a blog in another tab. This is a Tor feature that Mozilla has +also implemented in Firefox. + +\subsubsection{Usability testing and global outreach} +\label{ux-testing-outreach} + +To make useful software, especially software that aims to keep people safe, it +is essential to understand users' contexts and goals. This is especially true +for tools that require some level of technical knowledge to use successfully, +such as tools for evading censorship. + +As part of our global south initiative, members of the Tor user experience and +community teams traveled through India, Uganda, Colombia, and Kenya to run +usability testing. We ran in-person testing of several user experience (UX) +improvements in Tor Browser 8.0 with users of different technical backgrounds. +We conducted more than 45 interviews~\cite{ux-research} that gave us an +understanding of the diverse mental models and technical levels of knowledge of +our users. + +We met people like Juana, a coffee farmer in Colombia who is part of a +self-managed group of women coffee growers. The group uses Tor to communicate +securely with one another. We met Jon, an environmental activist and journalist +in Hoima, Uganda who uses Tor to anonymously publish his blog. + +We learned about several threat models (Figure~\ref{uganda-threat-model}) of the people +we spoke to in Uganda. Concern about local police retaining hardware devices, +and the practice of the political party currently in power seizing journalists +notes and other records, were common in most of these communities. + +\begin{figure} +\begin{center} +\fbox{\includegraphics[width=0.8\textwidth]{task7b/threat-model-uganda-debrief.png}} +\end{center} +\caption{Threat Model.} +\label{uganda-threat-model} +\end{figure} + +In addition, this work allowed us to speak with people who use our software +under extreme conditions, such as poor telecommunications infrastructure, very +expensive data packages or very old hardware. This helped us to understand +their context, empathize, and consider solutions that work for them. We believe +that Tor Browser must be usable by people without a technical background, as +well as by advanced users. We want to empower our users through education so +that they can have control of their browsing. + +We use an open design process~\cite{opendesignkit} +where developers and designers work together to achieve the best solution. We +use knowledge gained from our research to help us to create the most usable +flow for users. + +As part of user education, Tor Browser's on-boarding---a short in-browser +orientation provided when a user first opens the application---aims to teach +users the complex concepts underlying the Tor network using local language +metaphors and simple words. + +In many places, Tor Browser is considered to be the highest standard for +protecting people's privacy and helping them evade censorship. However, many +people who learn about Tor express fear, at first, based on stories they have +heard or misconceptions they have. Our on-boarding aims to give our users +confidence by explaining how Tor's privacy and security measures can protect +them. All of the information we give to users is especially critical when +users are in censored environments. They need to understand the trade-offs +and the risks they may run when they decide to opt in or opt out of a feature. + +After the user downloads Tor Browser, installs it successfully, and first +starts it, if they are in a censored country, they need to make decisions about using bridges and pluggable transports. +But not all of our users know whether they are in a censored location. +An important subject for future work is exploring the technical options for +detecting whether the location is censored without compromising user safety. +We could probe the internet from Tor Browser to detect whether the user's +connection is being censored and then automatically configure bridges and +pluggable transports. This would certainly improve Tor Browser's usability. +However, such probing may be detectable by the censor and alert them to the +fact that the user has Tor Browser installed, which may not be desirable. +Currently, Tor Browser errs on the side of safety and does not attempt to +establish any connections until the user configures it. + +In the future, with the help of OONI (see Section~\ref{censorship-of-tor}) and +Tor Metrics (see Section~\ref{sec:public-datasets}), we should have a good idea +of the state of censorship and network interference for most countries. When we +know this, we can provide users with suggestions about how to set up their Tor +Browser to get around censorship based on their locations. + +Tor Browser 8.0 also includes a new circuit display (Figure~\ref{new-circuit-display}), +which shows the relays the current browser tab is using. This visual aid +helps improve user understanding of how Tor sends their traffic through the Tor +network. + +\begin{figure} +\begin{center} +\fbox{\includegraphics[width=0.8\textwidth]{task7b/onion-circuit-display.png}} +\end{center} +\caption{New Circuit Display} +\label{new-circuit-display} +\end{figure} + +\subsection{Tor Browser for Android} +\label{tb-android} + +Historically, Tor Browser has only been developed for desktop computers running +Microsoft Windows, Mac OS X, and various distributions of Linux. But most +people now use mobile devices, either as their primary means of getting on the +internet, or at least in addition to using desktop computers. In the past, Tor +relied on partner organizations to make mobile browsers that connect to the Tor +network. Recently, however, we've begun making significant progress on Android +support ourselves. + +At the beginning of September 2018, we released the first alpha version of Tor +Browser for Android. This work is heavily based on the Guardian Project's +Android app Orfox. Orfox provides a Tor-connected private web browser on +Android, but doesn't come with all of the privacy protections that are in the +desktop version of Tor Browser. The goal of our recent work in this area is to +provide an Android app that gives users a private browser on Android equivalent +to Tor Browser on desktop. + +The current alpha version of Tor Browser for Android still requires an +additional app, Orbot, that connects the browser to the Tor network. In the +near future, Tor Browser for Android will include Tor as part of the app, +making it easier to install and use. + +Tor Browser for Android provides an on-boarding experience for new users that +is similar to the one provided for desktop. This helps new users understand how Tor works to protect their privacy. + +The current version of the app does not directly support methods for +circumventing censorship\textemdash we rely on Orbot for this, as well. Similar to +Tor Browser on desktop, Orbot supports the meek and obfs4 pluggable transports. +These provide users with some of the best censorship circumvention techniques +available today. + +When a user configures Orbot to use a language that is primarily used in +certain censored countries, it automatically configures and enables the meek +pluggable transport to help the user get around censorship. + +The user can always select and configure another bridge from Orbot's home +screen, if necessary. This screen gives users four options: + +\begin{itemize} + + \item If a bridge is already configured, then the user can choose to + directly connect to the Tor network without using a bridge. + + \item The user can enable one of the built-in obfs4 bridges (called + \emph{community servers}). + + \item The user can enable one of the built-in meek bridges (called + \emph{cloud servers}). + + \item The user can request another bridge from BridgeDB at + bridges.torproject.org. The user would then need to configure the bridge + manually using Orbot's Settings menu. +\end{itemize} + +In the future, like Tor Browser for desktop, Orbot and Tor Browser for Android +will support \emph{moat} to make requesting and configuring bridges and +new pluggable +transports easy. + +When Tor Browser for Android can connect to the Tor network without the +assistance of Orbot, we still envision the two being able to help each other, +perhaps by sharing configuration information. For example, if a user already +has Orbot installed to connect a different app to the Tor network, when they +install Tor Browser for Android, it could automatically configure itself to use +the bridges that Orbot uses. + +Our goal is to make Tor Browser for Android support all of our existing methods +to get around censorship. As research and development continue, we will add +new pluggable transports like Snowflake. We hope to learn from the work the +Guardian Project is doing in this area, as described in +Section~\ref{pt:snowflake}. + +As we do further work on Tor Browser for Android to include the features that +are already in Tor Browser for desktop, we plan to implement many of the user +interface improvements discussed in Section~\ref{browser-censorship}. But +because mobile displays are very different from desktop browsers, some of +these, such as the circuit display that shows the user which relays the browser +is using, will need to be redesigned. + +We also plan to add an indicator that will let users know when they are +connected to a website running an onion service, so they can tell that +their connection is more secure than a connection to the regular web. + +One subject of ongoing investigation is browser fingerprinting. The information +the browser exposes to websites can be used to identify either an individual +user or a group of users. Mobile devices have more physical sensors than +stationary computers, and that exposes more potential pieces of information +from which to construct a fingerprint. diff --git a/2018/sponsor19/report1/task7b/onion-circuit-display.png b/2018/sponsor19/report1/task7b/onion-circuit-display.png new file mode 100644 index 0000000..5ba817e Binary files /dev/null and b/2018/sponsor19/report1/task7b/onion-circuit-display.png differ diff --git a/2018/sponsor19/report1/task7b/threat-model-uganda-debrief.png b/2018/sponsor19/report1/task7b/threat-model-uganda-debrief.png new file mode 100644 index 0000000..2215dfe Binary files /dev/null and b/2018/sponsor19/report1/task7b/threat-model-uganda-debrief.png differ diff --git a/2018/sponsor19/report1/task8.tex b/2018/sponsor19/report1/task8.tex new file mode 100644 index 0000000..09d44bb --- /dev/null +++ b/2018/sponsor19/report1/task8.tex @@ -0,0 +1,158 @@ + +\section{Tor's role in the research community} + +Just about every major computer security conference these days has a paper +analyzing, attacking, or improving Tor. While fifteen years ago the field of +anonymous communications was mostly theoretical, with researchers speculating +that a given design should or shouldn't work, Tor now provides an actual +deployed testbed. Tor has become the gold standard for anonymous communications +research for three main reasons: + +First, Tor's source code and specifications are open. Beyond its original +design document~\cite{tor-design}, Tor provides a clear and published set +of technical specifications~\cite{tor-specs} describing exactly how it +is built, why we made each design decision, and what security properties +it aims to offer. The Tor developers conduct design discussion in the +open, on public development mailing lists, and the public development +proposal process~\cite{tor-proposals} provides a clear path by which +other researchers can participate. + +Second, Tor provides open APIs and maintains a set of tools to +help researchers and developers interact with the Tor software. The +Tor software's ``control port''~\cite{control-spec} lets controller +programs view and change configuration and status information, as well +as influence path selection. We provide easy instructions for setting +up separate private Tor networks for testing~\cite{jansen2012shadow}. +This modularity makes Tor +more accessible to researchers because they can run their own experiments +using Tor without needing to modify the Tor program itself. + +Third, real users rely on Tor. Every day millions of people connect to the +Tor network and depend on it for a broad variety of security goals. In +addition to its emphasis on research and design, the Tor Project has +developed a reputation as a non-profit that fosters this community and +puts its users first. This real-world relevance motivates researchers +to help make sure Tor provides provably good security properties. + +Tor attracts researchers precisely because it brings in so many +problems that are hard to solve yet matter deeply to the world. How to protect +communications metadata is one of the key open research questions of the +century, and nobody has all the answers. Our best chance at solving it is for +researchers and developers all around the world to team up and work in the +open to build on each other's progress. + +Since starting Tor, we've done over 100 Tor talks to university +research groups all around the world, teaching grad students about these +open research problems in the areas of censorship circumvention (which +led to the explosion of pluggable transport ideas), privacy-preserving +measurement, traffic analysis resistance, scalability and performance, +and more. + +The result of that effort, and of Tor's success in general, is a flood of +research papers, plus a dozen research labs who regularly have students +who write their theses on Tor. The original Tor design paper from 2004 +now has over 4000 citations, and in 2014 Usenix picked that paper out +of all the security papers published in 2004 to win their Test of Time award. + +\subsection{Tor research resources} + +Resources for researchers are collected within the Tor Research +Portal~\cite{research-portal} which is currently undergoing a redesign. This +portal serves as a landing point for anyone interested in doing Tor-related +research. A mock-up of the redesigned portal can be seen in +Figure~\ref{fig:research-portal-mock}. + +\begin{figure} +\begin{center} +\fbox{\includegraphics[width=0.8\textwidth]{task8/researchportal.png}} +\end{center} +\caption{Mock-up of redesigned Tor Research Portal.} +\label{fig:research-portal-mock} +\end{figure} + +\subsubsection{Datasets} + +We've been collecting data to learn more about the Tor network: how many relays +and clients there are in the network, what capabilities they have, how fast the +network is, how many clients are connecting via bridges, what traffic exits the +network, etc. We are also developing tools to process these huge data archives +and come up with useful statistics. These datasets are described in more detail +in Section~\ref{sec:public-datasets}. + +\subsubsection{Measurement and attack tools} + +We're building a collection of tools that can be used to measure, analyze, or +perform attacks on Tor. Many research groups need to do similar +measurements (for example, change the Tor design in some way and then see if +communication delays are reduced), and we hope to help everybody standardize on +a few tools and then make them really good. Also, while there are some really +neat Tor attacks that people have published, it can be hard to track down +the code they used in their experiments. + +We need defenses too\textemdash not just attacks. Most researchers find it easy +and fun to come up with new attacks on anonymity systems. We've seen this +lately in terms of improved congestion attacks, attacks based on +remotely measuring latency or throughput, and so on. Knowing how things can go +wrong is important, and we recognize that the incentives in academia aren't +aligned with spending energy on designing defenses, but it sure would be great +to get more people working on how to address the attacks. + +\subsection{Tor research safety board} + +The research safety board is a group of researchers who study Tor, +and who want to \emph{minimize privacy risks while fostering a better +understanding of the Tor network and its users}. We aim to accomplish +this goal in three ways: + +\begin{itemize} +\item Develop and maintain a set of guidelines that researchers can +use to assess the safety of their Tor research. +\item Give feedback to researchers who use our guidelines to assess +the safety of their planned research. +\item Teach program committees about our guidelines, and encourage +reviewers to consider research safety when reviewing Tor papers. +\end{itemize} + +The board has seen early success in three ways. First, it has handled a +dozen or so cases, where research groups wrote their research plans and a +safety self-assessment and submitted them to the board. The board engaged in a +discussion with the researchers to help them flesh out their assessment and to +help them think through their safety plans. + +Second, there are a small but growing set of papers out there on +\emph{privacy-preserving measurement}, which expand the toolbox of safe ways to +do network-wide measurements. + +And third, major conferences like PETS and Usenix Security +are starting to ask authors about their safety board interactions when the +paper includes some questionable or concerning methodology, and mainstream +papers are starting to include an ``Ethics of Data Collection'' section +or the equivalent~\cite{deep-corr18}. + +To go with these successes, we have three things we want to do in the near term +to position the research safety board for further success. First, we need to +publish the details of more past cases, so future researchers can benefit from +reading them. One of the main goals of the safety board is to provide +historical examples so prospective researchers can get concrete ideas of how to +assess safety. Authors generally agree to publish their interactions, +but only after their paper has gone public---which means we need better ways of +tracking the status of old safety board cases and noticing when we can make +them public. + +Second, we need to improve our workflow for noticing and responding to new +cases. In the past we used a shared mailing list, but some people found it hard +to interact with. Now we use our own HotCRP instance, but there are some gaps +in the workflow for noticing and assigning new submissions, and we sometimes +miss them. The fundamental problem here is that we have only busy professors +involved. Maybe we need to expand the set of volunteers to include people who +can better manage submissions and coordinate review. + +Finally, we need to do more outreach to program +committees. We've heard anecdotes from several program committee +members who excitedly told us that they asked authors ``what the Tor +safety board thought''---and that's a fine first question, but it's +misunderstanding the intended role of the safety board. We don't want +to be the gatekeepers of Tor research. Ultimately, we want reviewers to +be demanding a discussion of safety in the paper, not a discussion of +the authors' interaction with the safety board. + diff --git a/2018/sponsor19/report1/task8/researchportal.png b/2018/sponsor19/report1/task8/researchportal.png new file mode 100644 index 0000000..90bd585 Binary files /dev/null and b/2018/sponsor19/report1/task8/researchportal.png differ diff --git a/2018/sponsor19/report1/task9.tex b/2018/sponsor19/report1/task9.tex new file mode 100644 index 0000000..e0472e7 --- /dev/null +++ b/2018/sponsor19/report1/task9.tex @@ -0,0 +1,318 @@ +Users, especially those on smartphones, want privacy and the ability to bypass censorship for more +than just web browsing. Millions of people use chat and social media +applications, create and share media files like images and video, and more. In +fact, since Tor's performance penalties are most visible for delay-sensitive +applications like web browsing, we would like to explore secure messaging and +other asynchronous applications. We want to consider more use cases than just +web browsing. + +\section{Existing apps that use Tor} +\label{apps-that-use-tor} + +As a first step, we would like to understand whether existing prototypes +and tools currently using Tor work with Youtube and other popular services. +These tools include messaging and email apps, secure operating systems, tools +that send traffic from existing apps over the Tor network, monitoring tools, +and file sharing apps. + +\subsection{Web browsers} + +In addition to Tor Browser, there are a number of web browsers that use the Tor network and protect users' privacy to varying degrees. These include OnionBrowser~\cite{onion-browser}, Brave~\cite{brave}, and Cliqz\cite{cliqz}. + +\subsection{Using mobile apps with the Tor network} + +The following apps send their internet traffic over the Tor network, whether by +using Tor's proxy interface, as Orbot does, or by providing a ``system-wide +VPN'' interface as iCepa does. + +\subsubsection{Orbot} + +Orbot~\cite{orbot} is an open-source app that allows other apps to send their +internet traffic through it and then through the Tor network, thereby hiding +the user's IP address. It includes an expert mode that allows users to make +all network connections through Tor. However, it requires user caution +as it does not provide any additional anti-tracking measures -- it is trivial +for apps or websites to track users in most web browsers and many other apps +even if the IP address is hidden. + +\subsubsection{iCepa} + +iCepa~\cite{icepa} is a new experimental app for connecting iOS apps to the Tor +network. iCepa is in alpha. + +\subsection{Communications} + +From peer to peer messaging apps, to email clients, there are a number +of different applications that people can use to anonymize their +communications: + +\subsubsection{Briar} + +Briar~\cite{briar} is an open source peer-to-peer messaging app for Android. +Briar sends its messages through the Tor network, preventing third parties from +observing which parties are communicating with each other or revealing their IP +addresses. + +\subsubsection{Ricochet} + +Ricochet~\cite{ricochet} is a desktop app that offers peer-to-peer messaging, +without exposing information about who is communicating. All messages are sent +wholly inside the Tor network. Ricochet uses Tor onion services to connect +users to one another, eliminating the central server that most messaging apps +use. + +\subsubsection{ChatSecure} +ChatSecure~\cite{chatsecure} is an open source iOS app offering optional Tor +support that hides the device's IP address and allows messages to bypass +restrictive firewalls. + +\subsubsection{TorBirdy} + +TorBirdy~\cite{tor-birdy} is an extension for Thunderbird, a desktop email +client, that is developed and maintained by members of the Tor Project. +TorBirdy sends email from Thunderbird over the Tor network. This means that the +email servers a message passes through do not learn the user's IP address. It +also hides email metadata to protect users' privacy. TorBirdy is in beta. + +\subsection{Secure operating systems} + +Currently there are a number of Linux-based operating systems which aim to +provide anonymity and privacy to their users. These OSes send their internet traffic through the Tor network. These include Tails (The Amnesic Incognito Live System)~\cite{tails}, Whonix~\cite{whonix}, and Qubes~\cite{qubes}. + +\subsection{Monitoring tools} + +\subsubsection{OONI Probe} + +OONI Probe~\cite{ooni-probe} is an app that runs on Mac OS X, Linux, Android, +and iOS that allows users to run tests to determine if their internet +connection is being censored or otherwise experiencing interference. +OONI is a Tor project that monitors and reports on +censorship around the world. See Section~\ref{ooni} for more information. + +\subsubsection{Haven} +Haven~\cite{haven} is an Android app that uses device sensors to monitor a +physical space. It detects motion, sound, vibration and light, and watches for +unexpected guests and intruders. It offers a Tor onion service feature that +allows the operator to connect to the device remotely and view its event +logs and +captured media. Haven is currently in beta. + +\subsection{File sharing} + +There are a few applications currently available which allow anonymous file +sharing over the Tor network: + +\subsubsection{OnionShare} + +OnionShare~\cite{onionshare} is a desktop app that allows users to send files to +one another over the Tor network. This prevents observers from seeing who is +sending and receiving the files. + +\subsubsection{GlobaLeaks} + +GlobaLeaks~\cite{globaleaks} is software that enables people and organizations +to set up their own secure, anonymous whistleblower platforms. When a user +creates a new deployment, GlobaLeaks sets up a Tor onion service. People +submitting documents can use Tor Browser to maintain anonymity when connecting +to the platform. + +There are a wide variety of GlobaLeaks deployments around the world for +purposes such as investigative journalism, anti-corruption activism, +transparency activism, and anti-crime activism. + +\subsubsection{SecureDrop} + +SecureDrop~\cite{securedrop} is server software that allows whistleblowers to +send files anonymously and securely to journalists. It functions as a Tor onion +service and requires whistleblowers to use Tor Browser to submit materials. +Over the past few years, it has become very common for major news organizations +to deploy SecureDrop. The New York Times, The Associated Press, The Guardian, +and ProPublica are just a few of the organizations that use SecureDrop. + +\subsubsection{OpenArchive} + +OpenArchive is a new app for Android for uploading and sharing media, including +video. It sends its traffic over the Tor network to the Internet Archive and +other archives. OpenArchive looks promising, but we need to examine whether +Open Archive solves the problems that actual users have and assess its +usability at accomplishing these goals. + +\section{Applications for users under censorship} + +We conducted a survey of the landscape of apps popular among users behind +censorship, and thought about how we can serve those users, considering both +safety and usability. Understanding what apps are popular with these users can +help us understand what would be useful to build, and what apps we should try +to make work with Tor. Internet censorship in China is particularly extensive, so if we consider solutions for users there, the lessons we learn may also apply in other contexts. + +We began with the assumption that most users in most censored places would want +to be using popular Android apps, since Android is the world's most popular +mobile operating system and users in most places will have the same usage +habits as one another. Popular apps include messaging apps, +social media apps, app stores, and video streaming and sharing +apps~\cite{popular-android-apps-wiki}. + +Many of these very popular apps such as WhatsApp, Telegram, Signal, Facebook, +Twitter, Netflix, Twitch, and Periscope are blocked in +China~\cite{china-blocked-apps}. In China, TenCent~\cite{tencent-wiki} +provides its own apps for messaging, social media, photo sharing, music +streaming, ebooks, e-sport streaming, and more~\cite{tencent-social}. It is +widely understood that Chinese government surveillance of these apps is +pervasive~\cite{tencent-surveillance}. + +All of these types of services could benefit from a Tor-based offering to +protect privacy and fight censorship. There are quite a few mobile VPNs that +claim to do this, but many don't do it well or safely. Virtual private networks +(VPNs) are very popular in China for circumventing censorship, but Chinese +authorities have taken steps to ban their use~\cite{china-vpn-ban}, with varying degrees of success. + +An obvious challenge is how to make apps and their updates available in places +where standard app stores such as Google Play and F-Droid are themselves +censored. + +Another important consideration is that people in China might not switch to +Tor to connect to a website or app because that website or app, as well as +Tor's documentation, lacks sufficient localization in Mandarin or Cantonese. +How do we address this problem with localization in mind? Do we simply assume +that people will generally switch over and add Chinese content back to the +larger web? Do we accept that we may only be serving English-speaking users in +China to some degree? Realistically we only have control over our own products, +and making translation apps usable through Tor, but it's an important thing to +bear in mind when trying to answer the question ``can we make this popular app +work with Tor for users in China?'' + +% We might use some of this later. +% +%Highly popular apps on Android devices (some TenCent alternatives are listed next to apps blocked in China): +%\begin{itemize} +% \item Messaging +% \begin{itemize} +% \item WhatsApp (blocked in China) (TenCent: QQ/WeChat) +% \item Facebook Messenger (blocked in China) (TenCent: QQ/WeChat) +% \item Discord +% \item Telegram( blocked in China) (TenCent: QQ/WeChat) +% \item LINE (blocked in China) (TenCent: QQ/WeChat) +% \item KaKao Talk (blocked in China) (TenCent: QQ/WeChat) +% \item Signal (blocked in China) (TenCent: QQ/WeChat) +% \end{itemize} +% \item Video Chat +% \begin{itemize} +% \item Hangouts +% \item Skype +% \end{itemize} +% \item Social Media +% \begin{itemize} +% \item Instagram +% \item Facebook (blocked in China) (TenCent: QZone - also used to upload videos) +% \item SnapChat +% \item Twitter (blocked in China) (TenCent: Weibo, QZone - also used to upload videos) +% \item Pinterest +% \item Google+ +% \item Tinder +% \end{itemize} +% \item Content Browsing +% \begin{itemize} +% \item Google Play Books (blocked in China) (TenCent: China Reading Limited (Tencent Literature)) +% \item Google News +% \item Reddit +% \item Blogspot +% \item Reddit +% \item Flickr +% \end{itemize} +% \item Utilities +% \begin{itemize} +% \item Google Translate +% \item Google Street View +% \item Google Maps +% \end{itemize} +% \item Search Engines +% \begin{itemize} +% \item Search Engines +% \item Google +% \item DuckDuckGo +% \item Yahoo +% \item Bing (accessible in China but some search results are censored) +% \end{itemize} +% \item Streaming websites and apps +% \begin{itemize} +% \item Youtube +% \item Netflix (blocked in China) \todo{(TenCent: TenCent Pictures, maybe?)} +% \item Vimeo +% \item Dailymotion +% \item Twitch (blocked in China) (TenCent: Penguin e-Sports) +% \item Periscope (NOW Live) (blocked in China) (TenCent: QZone) +% \end{itemize} +% \item{Email} +% \begin{itemize} +% \item Gmail +% \end{itemize} +% \item Cloud Storage \& Productivity +% \begin{itemize} +% \item Dropbox +% \item Google Drive +% \item Google Docs +% \item Scribd +% \item Slack +% \end{itemize} +% \item News \& Information websites +% \begin{itemize} +% \item New York Times +% \item The Economist +% \item Bloomberg +% \item Wall Street Journal +% \item Reuters +% \item Wikipedia (English) +% \item The Guardian +% \item Le Monde +% \item CNN +% \item BBC +% \item ABC +% \end{itemize} +%\end{itemize} +% +% +%\subsection{TenCent apps and services} +% +%\subsubsection{WeChat} +% +%"Weixin/WeChat reached more than 938 million monthly active user accounts as of +%the first quarter of 2017."~\cite{tencent-social} +% +%\subsubsection{QQ} +% +%QQ is an instant messaging app potentially aimed at younger users, complete +%with comics, games, and a payment service built in. +% +%"As of the first quarter of 2017, QQ had 861 million monthly active user +%accounts and more than 266 million people were using QQ +%simultaneously."~\cite{tencent-social} +% +%\subsubsection{QZone} +% +%Qzone is a social media platform. It allows image and video upload, live +%streaming, games, blog posts, etc. Might be an important focus later on, given +%our one-sentence goal for this project. +% +%"Qzone Album records peak daily uploads of 650 million photos and total uploads +%of 2 trillion photos.As of the first quarter of 2017, Qzone had 632 million +%monthly active user accounts."~\cite{tencent-social}. +% +%\subsubsection{China Reading Limited (Tencent Literature)} +% +%"China Reading Limited brings the full integration of online and traditional +%literary works to one platform."\cite{tencent-social} +% +%\subsubsection{QQ Music} +% +%QQ Music is a music streaming service.\cite{tencent-social} +% +%\subsubsection{Penguin e-sports} +% +%Penguin e-sports is a mobile live-streaming service for e-sports, similar to +%Twitch.\cite{tencent-social} +% +%\subsubsection{NOW Live} +% +%NOW Live is a video live-streaming platform.\cite{tencent-social} +% +%\todo{expand research on the above platforms} diff --git a/2018/sponsor19/rfc.bib b/2018/sponsor19/rfc.bib new file mode 100644 index 0000000..27f6e9d --- /dev/null +++ b/2018/sponsor19/rfc.bib @@ -0,0 +1,181559 @@ +@misc{rfc1, + author="S. Crocker", + title="{Host Software}", + howpublished="RFC 1", + series="Internet Request for Comments", + type="RFC", + number="1", + pages="1--11", + year=1969, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1.txt", + key="RFC 1", + doi="10.17487/RFC0001", + } + +@misc{rfc2, + author="B. Duvall", + title="{Host software}", + howpublished="RFC 2", + series="Internet Request for Comments", + type="RFC", + number="2", + pages="1--10", + year=1969, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2.txt", + key="RFC 2", + doi="10.17487/RFC0002", + } + +@misc{rfc3, + author="S.D. Crocker", + title="{Documentation conventions}", + howpublished="RFC 3", + series="Internet Request for Comments", + type="RFC", + number="3", + pages="1--2", + year=1969, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 10", +url="https://www.rfc-editor.org/rfc/rfc3.txt", + key="RFC 3", + doi="10.17487/RFC0003", + } + +@misc{rfc4, + author="E.B. Shapiro", + title="{Network timetable}", + howpublished="RFC 4", + series="Internet Request for Comments", + type="RFC", + number="4", + pages="1--6", + year=1969, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4.txt", + key="RFC 4", + doi="10.17487/RFC0004", + } + +@misc{rfc5, + author="J. Rulifson", + title="{Decode Encode Language (DEL)}", + howpublished="RFC 5", + series="Internet Request for Comments", + type="RFC", + number="5", + pages="1--17", + year=1969, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5.txt", + key="RFC 5", + doi="10.17487/RFC0005", + } + +@misc{rfc6, + author="S.D. Crocker", + title="{Conversation with Bob Kahn}", + howpublished="RFC 6", + series="Internet Request for Comments", + type="RFC", + number="6", + pages="1--1", + year=1969, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6.txt", + key="RFC 6", + doi="10.17487/RFC0006", + } + +@misc{rfc7, + author="G. Deloche", + title="{Host-IMP interface}", + howpublished="RFC 7", + series="Internet Request for Comments", + type="RFC", + number="7", + pages="1--7", + year=1969, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7.txt", + key="RFC 7", + doi="10.17487/RFC0007", + } + +@misc{rfc8, + author="G. Deloche", + title="{ARPA Network Functional Specifications}", + howpublished="RFC 8", + series="Internet Request for Comments", + type="RFC", + number="8", + year=1969, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8.txt", + key="RFC 8", + doi="10.17487/RFC0008", + } + +@misc{rfc9, + author="G. Deloche", + title="{Host Software}", + howpublished="RFC 9", + series="Internet Request for Comments", + type="RFC", + number="9", + year=1969, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc9.txt", + key="RFC 9", + doi="10.17487/RFC0009", + } + +@misc{rfc10, + author="S.D. Crocker", + title="{Documentation conventions}", + howpublished="RFC 10", + series="Internet Request for Comments", + type="RFC", + number="10", + pages="1--3", + year=1969, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 16, updated by RFCs 24, 27, 30", +url="https://www.rfc-editor.org/rfc/rfc10.txt", + key="RFC 10", + doi="10.17487/RFC0010", + } + +@misc{rfc11, + author="G. Deloche", + title="{Implementation of the Host - Host Software Procedures in GORDO}", + howpublished="RFC 11", + series="Internet Request for Comments", + type="RFC", + number="11", + pages="1--23", + year=1969, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 33", +url="https://www.rfc-editor.org/rfc/rfc11.txt", + key="RFC 11", + doi="10.17487/RFC0011", + } + +@misc{rfc12, + author="M. Wingfield", + title="{IMP-Host interface flow diagrams}", + howpublished="RFC 12", + series="Internet Request for Comments", + type="RFC", + number="12", + pages="1--1", + year=1969, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc12.txt", + key="RFC 12", + doi="10.17487/RFC0012", + } + +@misc{rfc13, + author="V. Cerf", + title="{Zero Text Length EOF Message}", + howpublished="RFC 13", + series="Internet Request for Comments", + type="RFC", + number="13", + pages="1--1", + year=1969, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc13.txt", + key="RFC 13", + doi="10.17487/RFC0013", + } + +@misc{rfc15, + author="C.S. Carr", + title="{Network subsystem for time sharing hosts}", + howpublished="RFC 15", + series="Internet Request for Comments", + type="RFC", + number="15", + pages="1--5", + year=1969, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc15.txt", + key="RFC 15", + doi="10.17487/RFC0015", + } + +@misc{rfc16, + author="S. Crocker", + title="{M.I.T}", + howpublished="RFC 16", + series="Internet Request for Comments", + type="RFC", + number="16", + pages="1--1", + year=1969, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 24, updated by RFCs 24, 27, 30", +url="https://www.rfc-editor.org/rfc/rfc16.txt", + key="RFC 16", + doi="10.17487/RFC0016", + } + +@misc{rfc17, + author="J.E. Kreznar", + title="{Some questions re: Host-IMP Protocol}", + howpublished="RFC 17", + series="Internet Request for Comments", + type="RFC", + number="17", + pages="1--4", + year=1969, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc17.txt", + key="RFC 17", + doi="10.17487/RFC0017", + } + +@misc{rfc18, + author="V. Cerf", + title="{IMP-IMP and HOST-HOST Control Links}", + howpublished="RFC 18", + series="Internet Request for Comments", + type="RFC", + number="18", + pages="1--1", + year=1969, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc18.txt", + key="RFC 18", + doi="10.17487/RFC0018", + } + +@misc{rfc19, + author="J.E. Kreznar", + title="{Two protocol suggestions to reduce congestion at swap bound nodes}", + howpublished="RFC 19", + series="Internet Request for Comments", + type="RFC", + number="19", + pages="1--2", + year=1969, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc19.txt", + key="RFC 19", + doi="10.17487/RFC0019", + } + +@misc{rfc20, + author="V.G. Cerf", + title="{ASCII format for network interchange}", + howpublished="RFC 20 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="20", + pages="1--9", + year=1969, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc20.txt", + key="RFC 20", + doi="10.17487/RFC0020", + } + +@misc{rfc21, + author="V.G. Cerf", + title="{Network meeting}", + howpublished="RFC 21", + series="Internet Request for Comments", + type="RFC", + number="21", + pages="1--2", + year=1969, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc21.txt", + key="RFC 21", + doi="10.17487/RFC0021", + } + +@misc{rfc22, + author="V.G. Cerf", + title="{Host-host control message formats}", + howpublished="RFC 22", + series="Internet Request for Comments", + type="RFC", + number="22", + pages="1--2", + year=1969, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc22.txt", + key="RFC 22", + doi="10.17487/RFC0022", + } + +@misc{rfc23, + author="G. Gregg", + title="{Transmission of Multiple Control Messages}", + howpublished="RFC 23", + series="Internet Request for Comments", + type="RFC", + number="23", + pages="1--1", + year=1969, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc23.txt", + key="RFC 23", + doi="10.17487/RFC0023", + } + +@misc{rfc24, + author="S.D. Crocker", + title="{Documentation Conventions}", + howpublished="RFC 24", + series="Internet Request for Comments", + type="RFC", + number="24", + pages="1--3", + year=1969, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 27, 30", +url="https://www.rfc-editor.org/rfc/rfc24.txt", + key="RFC 24", + doi="10.17487/RFC0024", + } + +@misc{rfc25, + author="S.D. Crocker", + title="{No High Link Numbers}", + howpublished="RFC 25", + series="Internet Request for Comments", + type="RFC", + number="25", + pages="1--1", + year=1969, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc25.txt", + key="RFC 25", + doi="10.17487/RFC0025", + } + +@misc{rfc27, + author="S.D. Crocker", + title="{Documentation Conventions}", + howpublished="RFC 27", + series="Internet Request for Comments", + type="RFC", + number="27", + pages="1--3", + year=1969, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 30", +url="https://www.rfc-editor.org/rfc/rfc27.txt", + key="RFC 27", + doi="10.17487/RFC0027", + } + +@misc{rfc28, + author="W.K. English", + title="{Time Standards}", + howpublished="RFC 28", + series="Internet Request for Comments", + type="RFC", + number="28", + pages="1--1", + year=1970, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc28.txt", + key="RFC 28", + doi="10.17487/RFC0028", + } + +@misc{rfc29, + author="R.E. Kahn", + title="{Response to RFC 28}", + howpublished="RFC 29", + series="Internet Request for Comments", + type="RFC", + number="29", + pages="1--1", + year=1970, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc29.txt", + key="RFC 29", + doi="10.17487/RFC0029", + } + +@misc{rfc30, + author="S.D. Crocker", + title="{Documentation Conventions}", + howpublished="RFC 30", + series="Internet Request for Comments", + type="RFC", + number="30", + pages="1--3", + year=1970, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc30.txt", + key="RFC 30", + doi="10.17487/RFC0030", + } + +@misc{rfc31, + author="D. Bobrow and W.R. Sutherland", + title="{Binary Message Forms in Computer}", + howpublished="RFC 31", + series="Internet Request for Comments", + type="RFC", + number="31", + pages="1--7", + year=1968, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc31.txt", + key="RFC 31", + doi="10.17487/RFC0031", + } + +@misc{rfc32, + author="J. Cole", + title="{Some Thoughts on SRI's Proposed Real Time Clock}", + howpublished="RFC 32", + series="Internet Request for Comments", + type="RFC", + number="32", + pages="1--1", + year=1970, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc32.txt", + key="RFC 32", + doi="10.17487/RFC0032", + } + +@misc{rfc33, + author="S.D. Crocker", + title="{New Host-Host Protocol}", + howpublished="RFC 33", + series="Internet Request for Comments", + type="RFC", + number="33", + pages="1--19", + year=1970, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 36, 47", +url="https://www.rfc-editor.org/rfc/rfc33.txt", + key="RFC 33", + doi="10.17487/RFC0033", + } + +@misc{rfc34, + author="W.K. English", + title="{Some Brief Preliminary Notes on the Augmentation Research Center Clock}", + howpublished="RFC 34", + series="Internet Request for Comments", + type="RFC", + number="34", + pages="1--2", + year=1970, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc34.txt", + key="RFC 34", + doi="10.17487/RFC0034", + } + +@misc{rfc35, + author="S.D. Crocker", + title="{Network Meeting}", + howpublished="RFC 35 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="35", + pages="1--1", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc35.txt", + key="RFC 35", + doi="10.17487/RFC0035", + } + +@misc{rfc36, + author="S.D. Crocker", + title="{Protocol Notes}", + howpublished="RFC 36", + series="Internet Request for Comments", + type="RFC", + number="36", + pages="1--8", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 39, 44", +url="https://www.rfc-editor.org/rfc/rfc36.txt", + key="RFC 36", + doi="10.17487/RFC0036", + } + +@misc{rfc37, + author="S.D. Crocker", + title="{Network Meeting Epilogue, etc}", + howpublished="RFC 37", + series="Internet Request for Comments", + type="RFC", + number="37", + pages="1--5", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc37.txt", + key="RFC 37", + doi="10.17487/RFC0037", + } + +@misc{rfc38, + author="S.M. Wolfe", + title="{Comments on Network Protocol from NWG/RFC \#36}", + howpublished="RFC 38", + series="Internet Request for Comments", + type="RFC", + number="38", + pages="1--1", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc38.txt", + key="RFC 38", + doi="10.17487/RFC0038", + } + +@misc{rfc39, + author="E. Harslem and J.F. Heafner", + title="{Comments on Protocol Re: NWG/RFC \#36}", + howpublished="RFC 39", + series="Internet Request for Comments", + type="RFC", + number="39", + pages="1--3", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc39.txt", + key="RFC 39", + doi="10.17487/RFC0039", + } + +@misc{rfc40, + author="E. Harslem and J.F. Heafner", + title="{More Comments on the Forthcoming Protocol}", + howpublished="RFC 40", + series="Internet Request for Comments", + type="RFC", + number="40", + pages="1--3", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc40.txt", + key="RFC 40", + doi="10.17487/RFC0040", + } + +@misc{rfc41, + author="J.T. Melvin", + title="{IMP-IMP Teletype Communication}", + howpublished="RFC 41", + series="Internet Request for Comments", + type="RFC", + number="41", + pages="1--1", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc41.txt", + key="RFC 41", + doi="10.17487/RFC0041", + } + +@misc{rfc42, + author="E. Ancona", + title="{Message Data Types}", + howpublished="RFC 42", + series="Internet Request for Comments", + type="RFC", + number="42", + pages="1--3", + year=1970, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc42.txt", + key="RFC 42", + doi="10.17487/RFC0042", + } + +@misc{rfc43, + author="A.G. Nemeth", + title="{Proposed Meeting}", + howpublished="RFC 43", + series="Internet Request for Comments", + type="RFC", + number="43", + pages="1--2", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc43.txt", + key="RFC 43", + doi="10.17487/RFC0043", + } + +@misc{rfc44, + author="A. Shoshani and R. Long and A. Landsberg", + title="{Comments on NWG/RFC 33 and 36}", + howpublished="RFC 44", + series="Internet Request for Comments", + type="RFC", + number="44", + pages="1--3", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc44.txt", + key="RFC 44", + doi="10.17487/RFC0044", + } + +@misc{rfc45, + author="J. Postel and S.D. Crocker", + title="{New Protocol is Coming}", + howpublished="RFC 45", + series="Internet Request for Comments", + type="RFC", + number="45", + pages="1--1", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc45.txt", + key="RFC 45", + doi="10.17487/RFC0045", + } + +@misc{rfc46, + author="E. Meyer", + title="{ARPA Network protocol notes}", + howpublished="RFC 46", + series="Internet Request for Comments", + type="RFC", + number="46", + pages="1--17", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc46.txt", + key="RFC 46", + doi="10.17487/RFC0046", + } + +@misc{rfc47, + author="J. Postel and S. Crocker", + title="{BBN's Comments on NWG/RFC \#33}", + howpublished="RFC 47", + series="Internet Request for Comments", + type="RFC", + number="47", + pages="1--4", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc47.txt", + key="RFC 47", + doi="10.17487/RFC0047", + } + +@misc{rfc48, + author="J. Postel and S.D. Crocker", + title="{Possible protocol plateau}", + howpublished="RFC 48", + series="Internet Request for Comments", + type="RFC", + number="48", + pages="1--18", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc48.txt", + key="RFC 48", + doi="10.17487/RFC0048", + } + +@misc{rfc49, + author="E. Meyer", + title="{Conversations with S. Crocker (UCLA)}", + howpublished="RFC 49", + series="Internet Request for Comments", + type="RFC", + number="49", + pages="1--5", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc49.txt", + key="RFC 49", + doi="10.17487/RFC0049", + } + +@misc{rfc50, + author="E. Harslen and J. Heafner", + title="{Comments on the Meyer Proposal}", + howpublished="RFC 50", + series="Internet Request for Comments", + type="RFC", + number="50", + pages="1--2", + year=1970, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc50.txt", + key="RFC 50", + doi="10.17487/RFC0050", + } + +@misc{rfc51, + author="M. Elie", + title="{Proposal for a Network Interchange Language}", + howpublished="RFC 51", + series="Internet Request for Comments", + type="RFC", + number="51", + year=1970, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc51.txt", + key="RFC 51", + doi="10.17487/RFC0051", + } + +@misc{rfc52, + author="J. Postel and S.D. Crocker", + title="{Updated distribution list}", + howpublished="RFC 52", + series="Internet Request for Comments", + type="RFC", + number="52", + pages="1--3", + year=1970, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 69", +url="https://www.rfc-editor.org/rfc/rfc52.txt", + key="RFC 52", + doi="10.17487/RFC0052", + } + +@misc{rfc53, + author="S.D. Crocker", + title="{Official protocol mechanism}", + howpublished="RFC 53", + series="Internet Request for Comments", + type="RFC", + number="53", + pages="1--1", + year=1970, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc53.txt", + key="RFC 53", + doi="10.17487/RFC0053", + } + +@misc{rfc54, + author="S.D. Crocker and J. Postel and J. Newkirk and M. Kraley", + title="{Official Protocol Proffering}", + howpublished="RFC 54", + series="Internet Request for Comments", + type="RFC", + number="54", + pages="1--9", + year=1970, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 57", +url="https://www.rfc-editor.org/rfc/rfc54.txt", + key="RFC 54", + doi="10.17487/RFC0054", + } + +@misc{rfc55, + author="J. Newkirk and M. Kraley and J. Postel and S.D. Crocker", + title="{Prototypical implementation of the NCP}", + howpublished="RFC 55", + series="Internet Request for Comments", + type="RFC", + number="55", + pages="1--23", + year=1970, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc55.txt", + key="RFC 55", + doi="10.17487/RFC0055", + } + +@misc{rfc56, + author="E. Belove and D. Black and R. Flegal and L.G. Farquar", + title="{Third Level Protocol: Logger Protocol}", + howpublished="RFC 56", + series="Internet Request for Comments", + type="RFC", + number="56", + pages="1--6", + year=1970, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc56.txt", + key="RFC 56", + doi="10.17487/RFC0056", + } + +@misc{rfc57, + author="M. Kraley and J. Newkirk", + title="{Thoughts and Reflections on NWG/RFC 54}", + howpublished="RFC 57", + series="Internet Request for Comments", + type="RFC", + number="57", + pages="1--5", + year=1970, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc57.txt", + key="RFC 57", + doi="10.17487/RFC0057", + } + +@misc{rfc58, + author="T.P. Skinner", + title="{Logical Message Synchronization}", + howpublished="RFC 58", + series="Internet Request for Comments", + type="RFC", + number="58", + pages="1--2", + year=1970, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc58.txt", + key="RFC 58", + doi="10.17487/RFC0058", + } + +@misc{rfc59, + author="E. Meyer", + title="{Flow Control - Fixed Versus Demand Allocation}", + howpublished="RFC 59", + series="Internet Request for Comments", + type="RFC", + number="59", + pages="1--7", + year=1970, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc59.txt", + key="RFC 59", + doi="10.17487/RFC0059", + } + +@misc{rfc60, + author="R. Kalin", + title="{A Simplified NCP Protocol}", + howpublished="RFC 60", + series="Internet Request for Comments", + type="RFC", + number="60", + pages="1--8", + year=1970, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc60.txt", + key="RFC 60", + doi="10.17487/RFC0060", + } + +@misc{rfc61, + author="D.C. Walden", + title="{Note on Interprocess Communication in a Resource Sharing Computer Network}", + howpublished="RFC 61", + series="Internet Request for Comments", + type="RFC", + number="61", + pages="1--18", + year=1970, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 62", +url="https://www.rfc-editor.org/rfc/rfc61.txt", + key="RFC 61", + doi="10.17487/RFC0061", + } + +@misc{rfc62, + author="D.C. Walden", + title="{Systems for Interprocess Communication in a Resource Sharing Computer Network}", + howpublished="RFC 62", + series="Internet Request for Comments", + type="RFC", + number="62", + pages="1--20", + year=1970, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc62.txt", + key="RFC 62", + doi="10.17487/RFC0062", + } + +@misc{rfc63, + author="V.G. Cerf", + title="{Belated Network Meeting Report}", + howpublished="RFC 63", + series="Internet Request for Comments", + type="RFC", + number="63", + pages="1--2", + year=1970, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc63.txt", + key="RFC 63", + doi="10.17487/RFC0063", + } + +@misc{rfc64, + author="M. Elie", + title="{Getting rid of marking}", + howpublished="RFC 64", + series="Internet Request for Comments", + type="RFC", + number="64", + pages="1--4", + year=1970, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc64.txt", + key="RFC 64", + doi="10.17487/RFC0064", + } + +@misc{rfc65, + author="D.C. Walden", + title="{Comments on Host/Host Protocol document \#1}", + howpublished="RFC 65", + series="Internet Request for Comments", + type="RFC", + number="65", + pages="1--2", + year=1970, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc65.txt", + key="RFC 65", + doi="10.17487/RFC0065", + } + +@misc{rfc66, + author="S.D. Crocker", + title="{NIC - third level ideas and other noise}", + howpublished="RFC 66", + series="Internet Request for Comments", + type="RFC", + number="66", + pages="1--3", + year=1970, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 123, updated by RFCs 80, 93", +url="https://www.rfc-editor.org/rfc/rfc66.txt", + key="RFC 66", + doi="10.17487/RFC0066", + } + +@misc{rfc67, + author="W.R. Crowther", + title="{Proposed Change to Host/IMP Spec to Eliminate Marking}", + howpublished="RFC 67", + series="Internet Request for Comments", + type="RFC", + number="67", + pages="1--1", + year=1970, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc67.txt", + key="RFC 67", + doi="10.17487/RFC0067", + } + +@misc{rfc68, + author="M. Elie", + title="{Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM}", + howpublished="RFC 68", + series="Internet Request for Comments", + type="RFC", + number="68", + pages="1--2", + year=1970, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc68.txt", + key="RFC 68", + doi="10.17487/RFC0068", + } + +@misc{rfc69, + author="A.K. Bhushan", + title="{Distribution List Change for MIT}", + howpublished="RFC 69", + series="Internet Request for Comments", + type="RFC", + number="69", + pages="1--1", + year=1970, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc69.txt", + key="RFC 69", + doi="10.17487/RFC0069", + } + +@misc{rfc70, + author="S.D. Crocker", + title="{Note on Padding}", + howpublished="RFC 70", + series="Internet Request for Comments", + type="RFC", + number="70", + pages="1--9", + year=1970, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 228", +url="https://www.rfc-editor.org/rfc/rfc70.txt", + key="RFC 70", + doi="10.17487/RFC0070", + } + +@misc{rfc71, + author="T. Schipper", + title="{Reallocation in Case of Input Error}", + howpublished="RFC 71", + series="Internet Request for Comments", + type="RFC", + number="71", + pages="1--1", + year=1970, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc71.txt", + key="RFC 71", + doi="10.17487/RFC0071", + } + +@misc{rfc72, + author="R.D. Bressler", + title="{Proposed Moratorium on Changes to Network Protocol}", + howpublished="RFC 72", + series="Internet Request for Comments", + type="RFC", + number="72", + pages="1--4", + year=1970, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc72.txt", + key="RFC 72", + doi="10.17487/RFC0072", + } + +@misc{rfc73, + author="S.D. Crocker", + title="{Response to NWG/RFC 67}", + howpublished="RFC 73", + series="Internet Request for Comments", + type="RFC", + number="73", + pages="1--1", + year=1970, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc73.txt", + key="RFC 73", + doi="10.17487/RFC0073", + } + +@misc{rfc74, + author="J.E. White", + title="{Specifications for Network Use of the UCSB On-Line System}", + howpublished="RFC 74", + series="Internet Request for Comments", + type="RFC", + number="74", + pages="1--9", + year=1970, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 217, 225", +url="https://www.rfc-editor.org/rfc/rfc74.txt", + key="RFC 74", + doi="10.17487/RFC0074", + } + +@misc{rfc75, + author="S.D. Crocker", + title="{Network Meeting}", + howpublished="RFC 75", + series="Internet Request for Comments", + type="RFC", + number="75", + pages="1--1", + year=1970, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc75.txt", + key="RFC 75", + doi="10.17487/RFC0075", + } + +@misc{rfc76, + author="J. Bouknight and J. Madden and G.R. Grossman", + title="{Connection by name: User oriented protocol}", + howpublished="RFC 76", + series="Internet Request for Comments", + type="RFC", + number="76", + pages="1--15", + year=1970, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc76.txt", + key="RFC 76", + doi="10.17487/RFC0076", + } + +@misc{rfc77, + author="J. Postel", + title="{Network meeting report}", + howpublished="RFC 77", + series="Internet Request for Comments", + type="RFC", + number="77", + pages="1--9", + year=1970, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc77.txt", + key="RFC 77", + doi="10.17487/RFC0077", + } + +@misc{rfc78, + author="E. Harslem and J.F. Heafner and J.E. White", + title="{NCP Status Report: UCSB/Rand}", + howpublished="RFC 78", + series="Internet Request for Comments", + type="RFC", + number="78", + pages="1--1", + year=1970, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc78.txt", + key="RFC 78", + doi="10.17487/RFC0078", + } + +@misc{rfc79, + author="E. Meyer", + title="{Logger Protocol error}", + howpublished="RFC 79", + series="Internet Request for Comments", + type="RFC", + number="79", + pages="1--1", + year=1970, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc79.txt", + key="RFC 79", + doi="10.17487/RFC0079", + } + +@misc{rfc80, + author="E. Harslem and J.F. Heafner", + title="{Protocols and Data Formats}", + howpublished="RFC 80", + series="Internet Request for Comments", + type="RFC", + number="80", + pages="1--9", + year=1970, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 123, updated by RFC 93", +url="https://www.rfc-editor.org/rfc/rfc80.txt", + key="RFC 80", + doi="10.17487/RFC0080", + } + +@misc{rfc81, + author="J. Bouknight", + title="{Request for Reference Information}", + howpublished="RFC 81", + series="Internet Request for Comments", + type="RFC", + number="81", + pages="1--1", + year=1970, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc81.txt", + key="RFC 81", + doi="10.17487/RFC0081", + } + +@misc{rfc82, + author="E. Meyer", + title="{Network Meeting Notes}", + howpublished="RFC 82", + series="Internet Request for Comments", + type="RFC", + number="82", + pages="1--18", + year=1970, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc82.txt", + key="RFC 82", + doi="10.17487/RFC0082", + } + +@misc{rfc83, + author="R.H. Anderson and E. Harslem and J.F. Heafner", + title="{Language-machine for data reconfiguration}", + howpublished="RFC 83", + series="Internet Request for Comments", + type="RFC", + number="83", + pages="1--13", + year=1970, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc83.txt", + key="RFC 83", + doi="10.17487/RFC0083", + } + +@misc{rfc84, + author="J.B. North", + title="{List of NWG/RFC's 1-80}", + howpublished="RFC 84", + series="Internet Request for Comments", + type="RFC", + number="84", + pages="1--8", + year=1970, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc84.txt", + key="RFC 84", + doi="10.17487/RFC0084", + } + +@misc{rfc85, + author="S.D. Crocker", + title="{Network Working Group meeting}", + howpublished="RFC 85", + series="Internet Request for Comments", + type="RFC", + number="85", + pages="1--1", + year=1970, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc85.txt", + key="RFC 85", + doi="10.17487/RFC0085", + } + +@misc{rfc86, + author="S.D. Crocker", + title="{Proposal for a Network Standard Format for a Data Stream to Control Graphics Display}", + howpublished="RFC 86", + series="Internet Request for Comments", + type="RFC", + number="86", + pages="1--6", + year=1971, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 125", +url="https://www.rfc-editor.org/rfc/rfc86.txt", + key="RFC 86", + doi="10.17487/RFC0086", + } + +@misc{rfc87, + author="A. Vezza", + title="{Topic for Discussion at the Next Network Working Group Meeting}", + howpublished="RFC 87", + series="Internet Request for Comments", + type="RFC", + number="87", + pages="1--3", + year=1971, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc87.txt", + key="RFC 87", + doi="10.17487/RFC0087", + } + +@misc{rfc88, + author="R.T. Braden and S.M. Wolfe", + title="{NETRJS: A third level protocol for Remote Job Entry}", + howpublished="RFC 88", + series="Internet Request for Comments", + type="RFC", + number="88", + pages="1--9", + year=1971, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 189", +url="https://www.rfc-editor.org/rfc/rfc88.txt", + key="RFC 88", + doi="10.17487/RFC0088", + } + +@misc{rfc89, + author="R.M. Metcalfe", + title="{Some historic moments in networking}", + howpublished="RFC 89", + series="Internet Request for Comments", + type="RFC", + number="89", + pages="1--7", + year=1971, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc89.txt", + key="RFC 89", + doi="10.17487/RFC0089", + } + +@misc{rfc90, + author="R.T. Braden", + title="{CCN as a Network Service Center}", + howpublished="RFC 90", + series="Internet Request for Comments", + type="RFC", + number="90", + pages="1--6", + year=1971, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc90.txt", + key="RFC 90", + doi="10.17487/RFC0090", + } + +@misc{rfc91, + author="G.H. Mealy", + title="{Proposed User-User Protocol}", + howpublished="RFC 91", + series="Internet Request for Comments", + type="RFC", + number="91", + pages="1--12", + year=1970, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc91.txt", + key="RFC 91", + doi="10.17487/RFC0091", + } + +@misc{rfc93, + author="A.M. McKenzie", + title="{Initial Connection Protocol}", + howpublished="RFC 93", + series="Internet Request for Comments", + type="RFC", + number="93", + pages="1--1", + year=1971, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc93.txt", + key="RFC 93", + doi="10.17487/RFC0093", + } + +@misc{rfc94, + author="E. Harslem and J.F. Heafner", + title="{Some thoughts on Network Graphics}", + howpublished="RFC 94", + series="Internet Request for Comments", + type="RFC", + number="94", + pages="1--6", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc94.txt", + key="RFC 94", + doi="10.17487/RFC0094", + } + +@misc{rfc95, + author="S. Crocker", + title="{Distribution of NWG/RFC's through the NIC}", + howpublished="RFC 95", + series="Internet Request for Comments", + type="RFC", + number="95", + pages="1--5", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 155", +url="https://www.rfc-editor.org/rfc/rfc95.txt", + key="RFC 95", + doi="10.17487/RFC0095", + } + +@misc{rfc96, + author="R.W. Watson", + title="{An Interactive Network Experiment to Study Modes of Access the Network Information Center}", + howpublished="RFC 96 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="96", + pages="1--5", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc96.txt", + key="RFC 96", + doi="10.17487/RFC0096", + } + +@misc{rfc97, + author="J.T. Melvin and R.W. Watson", + title="{First Cut at a Proposed Telnet Protocol}", + howpublished="RFC 97", + series="Internet Request for Comments", + type="RFC", + number="97", + pages="1--11", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc97.txt", + key="RFC 97", + doi="10.17487/RFC0097", + } + +@misc{rfc98, + author="E. Meyer and T. Skinner", + title="{Logger Protocol Proposal}", + howpublished="RFC 98", + series="Internet Request for Comments", + type="RFC", + number="98", + pages="1--10", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 123", +url="https://www.rfc-editor.org/rfc/rfc98.txt", + key="RFC 98", + doi="10.17487/RFC0098", + } + +@misc{rfc99, + author="P.M. Karp", + title="{Network Meeting}", + howpublished="RFC 99", + series="Internet Request for Comments", + type="RFC", + number="99", + pages="1--1", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 116", +url="https://www.rfc-editor.org/rfc/rfc99.txt", + key="RFC 99", + doi="10.17487/RFC0099", + } + +@misc{rfc100, + author="P.M. Karp", + title="{Categorization and guide to NWG/RFCs}", + howpublished="RFC 100", + series="Internet Request for Comments", + type="RFC", + number="100", + pages="1--37", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc100.txt", + key="RFC 100", + doi="10.17487/RFC0100", + } + +@misc{rfc101, + author="R.W. Watson", + title="{Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971}", + howpublished="RFC 101", + series="Internet Request for Comments", + type="RFC", + number="101", + pages="1--14", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 108, 123", +url="https://www.rfc-editor.org/rfc/rfc101.txt", + key="RFC 101", + doi="10.17487/RFC0101", + } + +@misc{rfc102, + author="S.D. Crocker", + title="{Output of the Host-Host Protocol glitch cleaning committee}", + howpublished="RFC 102", + series="Internet Request for Comments", + type="RFC", + number="102", + pages="1--4", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 107", +url="https://www.rfc-editor.org/rfc/rfc102.txt", + key="RFC 102", + doi="10.17487/RFC0102", + } + +@misc{rfc103, + author="R.B. Kalin", + title="{Implementation of Interrupt Keys}", + howpublished="RFC 103", + series="Internet Request for Comments", + type="RFC", + number="103", + pages="1--4", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc103.txt", + key="RFC 103", + doi="10.17487/RFC0103", + } + +@misc{rfc104, + author="J.B. Postel and S.D. Crocker", + title="{Link 191}", + howpublished="RFC 104", + series="Internet Request for Comments", + type="RFC", + number="104", + pages="1--1", + year=1971, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc104.txt", + key="RFC 104", + doi="10.17487/RFC0104", + } + +@misc{rfc105, + author="J.E. White", + title="{Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB}", + howpublished="RFC 105", + series="Internet Request for Comments", + type="RFC", + number="105", + pages="1--9", + year=1971, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 217", +url="https://www.rfc-editor.org/rfc/rfc105.txt", + key="RFC 105", + doi="10.17487/RFC0105", + } + +@misc{rfc106, + author="T.C. O'Sullivan", + title="{User/Server Site Protocol Network Host Questionnaire}", + howpublished="RFC 106", + series="Internet Request for Comments", + type="RFC", + number="106", + pages="1--5", + year=1971, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc106.txt", + key="RFC 106", + doi="10.17487/RFC0106", + } + +@misc{rfc107, + author="R.D. Bressler and S.D. Crocker and W.R. Crowther and G.R. Grossman and R.S. Tomlinson and J.E. White", + title="{Output of the Host-Host Protocol Glitch Cleaning Committee}", + howpublished="RFC 107", + series="Internet Request for Comments", + type="RFC", + number="107", + pages="1--12", + year=1971, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 111, 124, 132, 154, 179", +url="https://www.rfc-editor.org/rfc/rfc107.txt", + key="RFC 107", + doi="10.17487/RFC0107", + } + +@misc{rfc108, + author="R.W. Watson", + title="{Attendance list at the Urbana NWG meeting, February 17-19, 1971}", + howpublished="RFC 108", + series="Internet Request for Comments", + type="RFC", + number="108", + pages="1--2", + year=1971, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc108.txt", + key="RFC 108", + doi="10.17487/RFC0108", + } + +@misc{rfc109, + author="J. Winett", + title="{Level III Server Protocol for the Lincoln Laboratory 360/67 Host}", + howpublished="RFC 109", + series="Internet Request for Comments", + type="RFC", + number="109", + pages="1--12", + year=1971, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc109.txt", + key="RFC 109", + doi="10.17487/RFC0109", + } + +@misc{rfc110, + author="J. Winett", + title="{Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts}", + howpublished="RFC 110", + series="Internet Request for Comments", + type="RFC", + number="110", + pages="1--4", + year=1971, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 135", +url="https://www.rfc-editor.org/rfc/rfc110.txt", + key="RFC 110", + doi="10.17487/RFC0110", + } + +@misc{rfc111, + author="S.D. Crocker", + title="{Pressure from the Chairman}", + howpublished="RFC 111", + series="Internet Request for Comments", + type="RFC", + number="111", + pages="1--2", + year=1971, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 130", +url="https://www.rfc-editor.org/rfc/rfc111.txt", + key="RFC 111", + doi="10.17487/RFC0111", + } + +@misc{rfc112, + author="T.C. O'Sullivan", + title="{User/Server Site Protocol: Network Host Questionnaire}", + howpublished="RFC 112", + series="Internet Request for Comments", + type="RFC", + number="112", + pages="1--1", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc112.txt", + key="RFC 112", + doi="10.17487/RFC0112", + } + +@misc{rfc113, + author="E. Harslem and J.F. Heafner and J.E. White", + title="{Network activity report: UCSB Rand}", + howpublished="RFC 113", + series="Internet Request for Comments", + type="RFC", + number="113", + pages="1--2", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 227", +url="https://www.rfc-editor.org/rfc/rfc113.txt", + key="RFC 113", + doi="10.17487/RFC0113", + } + +@misc{rfc114, + author="A.K. Bhushan", + title="{File Transfer Protocol}", + howpublished="RFC 114", + series="Internet Request for Comments", + type="RFC", + number="114", + pages="1--17", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 133, 141, 171, 172", +url="https://www.rfc-editor.org/rfc/rfc114.txt", + key="RFC 114", + keywords="FTP", + doi="10.17487/RFC0114", + } + +@misc{rfc115, + author="R.W. Watson and J.B. North", + title="{Some Network Information Center policies on handling documents}", + howpublished="RFC 115", + series="Internet Request for Comments", + type="RFC", + number="115", + pages="1--8", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc115.txt", + key="RFC 115", + doi="10.17487/RFC0115", + } + +@misc{rfc116, + author="S.D. Crocker", + title="{Structure of the May NWG Meeting}", + howpublished="RFC 116", + series="Internet Request for Comments", + type="RFC", + number="116", + pages="1--1", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 131, 156", +url="https://www.rfc-editor.org/rfc/rfc116.txt", + key="RFC 116", + doi="10.17487/RFC0116", + } + +@misc{rfc117, + author="J. Wong", + title="{Some comments on the official protocol}", + howpublished="RFC 117", + series="Internet Request for Comments", + type="RFC", + number="117", + pages="1--5", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc117.txt", + key="RFC 117", + doi="10.17487/RFC0117", + } + +@misc{rfc118, + author="R.W. Watson", + title="{Recommendations for facility documentation}", + howpublished="RFC 118", + series="Internet Request for Comments", + type="RFC", + number="118", + pages="1--2", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc118.txt", + key="RFC 118", + doi="10.17487/RFC0118", + } + +@misc{rfc119, + author="M. Krilanovich", + title="{Network Fortran Subprograms}", + howpublished="RFC 119", + series="Internet Request for Comments", + type="RFC", + number="119", + pages="1--19", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc119.txt", + key="RFC 119", + doi="10.17487/RFC0119", + } + +@misc{rfc120, + author="M. Krilanovich", + title="{Network PL1 subprograms}", + howpublished="RFC 120", + series="Internet Request for Comments", + type="RFC", + number="120", + pages="1--16", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc120.txt", + key="RFC 120", + doi="10.17487/RFC0120", + } + +@misc{rfc121, + author="M. Krilanovich", + title="{Network on-line operators}", + howpublished="RFC 121", + series="Internet Request for Comments", + type="RFC", + number="121", + pages="1--13", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc121.txt", + key="RFC 121", + doi="10.17487/RFC0121", + } + +@misc{rfc122, + author="J.E. White", + title="{Network specifications for UCSB's Simple-Minded File System}", + howpublished="RFC 122", + series="Internet Request for Comments", + type="RFC", + number="122", + pages="1--21", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 217, 269, 399, 431", +url="https://www.rfc-editor.org/rfc/rfc122.txt", + key="RFC 122", + doi="10.17487/RFC0122", + } + +@misc{rfc123, + author="S.D. Crocker", + title="{Proffered Official ICP}", + howpublished="RFC 123", + series="Internet Request for Comments", + type="RFC", + number="123", + pages="1--3", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 165, updated by RFCs 127, 143, 148", +url="https://www.rfc-editor.org/rfc/rfc123.txt", + key="RFC 123", + doi="10.17487/RFC0123", + } + +@misc{rfc124, + author="J.T. Melvin", + title="{Typographical error in RFC 107}", + howpublished="RFC 124", + series="Internet Request for Comments", + type="RFC", + number="124", + pages="1--1", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc124.txt", + key="RFC 124", + doi="10.17487/RFC0124", + } + +@misc{rfc125, + author="J. McConnell", + title="{Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream}", + howpublished="RFC 125", + series="Internet Request for Comments", + type="RFC", + number="125", + pages="1--4", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 177", +url="https://www.rfc-editor.org/rfc/rfc125.txt", + key="RFC 125", + doi="10.17487/RFC0125", + } + +@misc{rfc126, + author="J. McConnell", + title="{Graphics Facilities at Ames Research Center}", + howpublished="RFC 126", + series="Internet Request for Comments", + type="RFC", + number="126", + pages="1--1", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc126.txt", + key="RFC 126", + doi="10.17487/RFC0126", + } + +@misc{rfc127, + author="J. Postel", + title="{Comments on RFC 123}", + howpublished="RFC 127", + series="Internet Request for Comments", + type="RFC", + number="127", + pages="1--2", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 145, updated by RFC 151", +url="https://www.rfc-editor.org/rfc/rfc127.txt", + key="RFC 127", + doi="10.17487/RFC0127", + } + +@misc{rfc128, + author="J. Postel", + title="{Bytes}", + howpublished="RFC 128", + series="Internet Request for Comments", + type="RFC", + number="128", + pages="1--2", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc128.txt", + key="RFC 128", + doi="10.17487/RFC0128", + } + +@misc{rfc129, + author="E. Harslem and J. Heafner and E. Meyer", + title="{Request for comments on socket name structure}", + howpublished="RFC 129", + series="Internet Request for Comments", + type="RFC", + number="129", + pages="1--6", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 147", +url="https://www.rfc-editor.org/rfc/rfc129.txt", + key="RFC 129", + doi="10.17487/RFC0129", + } + +@misc{rfc130, + author="J.F. Heafner", + title="{Response to RFC 111: Pressure from the chairman}", + howpublished="RFC 130", + series="Internet Request for Comments", + type="RFC", + number="130", + pages="1--1", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc130.txt", + key="RFC 130", + doi="10.17487/RFC0130", + } + +@misc{rfc131, + author="E. Harslem and J.F. Heafner", + title="{Response to RFC 116: May NWG meeting}", + howpublished="RFC 131", + series="Internet Request for Comments", + type="RFC", + number="131", + pages="1--3", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc131.txt", + key="RFC 131", + doi="10.17487/RFC0131", + } + +@misc{rfc132, + author="J.E. White", + title="{Typographical Error in RFC 107}", + howpublished="RFC 132", + series="Internet Request for Comments", + type="RFC", + number="132", + pages="1--1", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 154", +url="https://www.rfc-editor.org/rfc/rfc132.txt", + key="RFC 132", + doi="10.17487/RFC0132", + } + +@misc{rfc133, + author="R.L. Sunberg", + title="{File Transfer and Error Recovery}", + howpublished="RFC 133", + series="Internet Request for Comments", + type="RFC", + number="133", + pages="1--4", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc133.txt", + key="RFC 133", + keywords="FTP", + doi="10.17487/RFC0133", + } + +@misc{rfc134, + author="A. Vezza", + title="{Network Graphics meeting}", + howpublished="RFC 134", + series="Internet Request for Comments", + type="RFC", + number="134", + pages="1--2", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc134.txt", + key="RFC 134", + doi="10.17487/RFC0134", + } + +@misc{rfc135, + author="W. Hathaway", + title="{Response to NWG/RFC 110}", + howpublished="RFC 135", + series="Internet Request for Comments", + type="RFC", + number="135", + pages="1--3", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc135.txt", + key="RFC 135", + doi="10.17487/RFC0135", + } + +@misc{rfc136, + author="R.E. Kahn", + title="{Host accounting and administrative procedures}", + howpublished="RFC 136", + series="Internet Request for Comments", + type="RFC", + number="136", + pages="1--4", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc136.txt", + key="RFC 136", + doi="10.17487/RFC0136", + } + +@misc{rfc137, + author="T.C. O'Sullivan", + title="{Telnet Protocol - a proposed document}", + howpublished="RFC 137", + series="Internet Request for Comments", + type="RFC", + number="137", + pages="1--11", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 139", +url="https://www.rfc-editor.org/rfc/rfc137.txt", + key="RFC 137", + doi="10.17487/RFC0137", + } + +@misc{rfc138, + author="R.H. Anderson and V.G. Cerf and E. Harslem and J.F. Heafner and J. Madden and R.M. Metcalfe and A. Shoshani and J.E. White and D.C.M. Wood", + title="{Status report on proposed Data Reconfiguration Service}", + howpublished="RFC 138", + series="Internet Request for Comments", + type="RFC", + number="138", + pages="1--23", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc138.txt", + key="RFC 138", + doi="10.17487/RFC0138", + } + +@misc{rfc139, + author="T.C. O'Sullivan", + title="{Discussion of Telnet Protocol}", + howpublished="RFC 139", + series="Internet Request for Comments", + type="RFC", + number="139", + pages="1--11", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 158", +url="https://www.rfc-editor.org/rfc/rfc139.txt", + key="RFC 139", + doi="10.17487/RFC0139", + } + +@misc{rfc140, + author="S.D. Crocker", + title="{Agenda for the May NWG meeting}", + howpublished="RFC 140", + series="Internet Request for Comments", + type="RFC", + number="140", + pages="1--4", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 149", +url="https://www.rfc-editor.org/rfc/rfc140.txt", + key="RFC 140", + doi="10.17487/RFC0140", + } + +@misc{rfc141, + author="E. Harslem and J.F. Heafner", + title="{Comments on RFC 114: A File Transfer Protocol}", + howpublished="RFC 141", + series="Internet Request for Comments", + type="RFC", + number="141", + pages="1--2", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc141.txt", + key="RFC 141", + keywords="FTP", + doi="10.17487/RFC0141", + } + +@misc{rfc142, + author="C. Kline and J. Wong", + title="{Time-Out Mechanism in the Host-Host Protocol}", + howpublished="RFC 142", + series="Internet Request for Comments", + type="RFC", + number="142", + pages="1--2", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc142.txt", + key="RFC 142", + doi="10.17487/RFC0142", + } + +@misc{rfc143, + author="W. Naylor and J. Wong and C. Kline and J. Postel", + title="{Regarding proffered official ICP}", + howpublished="RFC 143", + series="Internet Request for Comments", + type="RFC", + number="143", + pages="1--4", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 165", +url="https://www.rfc-editor.org/rfc/rfc143.txt", + key="RFC 143", + doi="10.17487/RFC0143", + } + +@misc{rfc144, + author="A. Shoshani", + title="{Data sharing on computer networks}", + howpublished="RFC 144", + series="Internet Request for Comments", + type="RFC", + number="144", + pages="1--6", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc144.txt", + key="RFC 144", + doi="10.17487/RFC0144", + } + +@misc{rfc145, + author="J. Postel", + title="{Initial Connection Protocol Control Commands}", + howpublished="RFC 145", + series="Internet Request for Comments", + type="RFC", + number="145", + pages="1--2", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 165, updated by RFC 143", +url="https://www.rfc-editor.org/rfc/rfc145.txt", + key="RFC 145", + doi="10.17487/RFC0145", + } + +@misc{rfc146, + author="P.M. Karp and D.B. McKay and D.C.M. Wood", + title="{Views on issues relevant to data sharing on computer networks}", + howpublished="RFC 146", + series="Internet Request for Comments", + type="RFC", + number="146", + pages="1--6", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc146.txt", + key="RFC 146", + doi="10.17487/RFC0146", + } + +@misc{rfc147, + author="J.M. Winett", + title="{Definition of a socket}", + howpublished="RFC 147", + series="Internet Request for Comments", + type="RFC", + number="147", + pages="1--3", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc147.txt", + key="RFC 147", + doi="10.17487/RFC0147", + } + +@misc{rfc148, + author="A.K. Bhushan", + title="{Comments on RFC 123}", + howpublished="RFC 148", + series="Internet Request for Comments", + type="RFC", + number="148", + pages="1--1", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc148.txt", + key="RFC 148", + doi="10.17487/RFC0148", + } + +@misc{rfc149, + author="S.D. Crocker", + title="{Best Laid Plans}", + howpublished="RFC 149", + series="Internet Request for Comments", + type="RFC", + number="149", + pages="1--1", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc149.txt", + key="RFC 149", + doi="10.17487/RFC0149", + } + +@misc{rfc150, + author="R.B. Kalin", + title="{Use of IPC Facilities: A Working Paper}", + howpublished="RFC 150", + series="Internet Request for Comments", + type="RFC", + number="150", + pages="1--11", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc150.txt", + key="RFC 150", + doi="10.17487/RFC0150", + } + +@misc{rfc151, + author="A. Shoshani", + title="{Comments on a proffered official ICP: RFCs 123, 127}", + howpublished="RFC 151", + series="Internet Request for Comments", + type="RFC", + number="151", + pages="1--2", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc151.txt", + key="RFC 151", + doi="10.17487/RFC0151", + } + +@misc{rfc152, + author="M. Wilber", + title="{SRI Artificial Intelligence status report}", + howpublished="RFC 152", + series="Internet Request for Comments", + type="RFC", + number="152", + pages="1--1", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc152.txt", + key="RFC 152", + doi="10.17487/RFC0152", + } + +@misc{rfc153, + author="J.T. Melvin and R.W. Watson", + title="{SRI ARC-NIC status}", + howpublished="RFC 153", + series="Internet Request for Comments", + type="RFC", + number="153", + pages="1--4", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc153.txt", + key="RFC 153", + doi="10.17487/RFC0153", + } + +@misc{rfc154, + author="S.D. Crocker", + title="{Exposition Style}", + howpublished="RFC 154", + series="Internet Request for Comments", + type="RFC", + number="154", + pages="1--1", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc154.txt", + key="RFC 154", + doi="10.17487/RFC0154", + } + +@misc{rfc155, + author="J.B. North", + title="{ARPA Network mailing lists}", + howpublished="RFC 155", + series="Internet Request for Comments", + type="RFC", + number="155", + pages="1--13", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 168", +url="https://www.rfc-editor.org/rfc/rfc155.txt", + key="RFC 155", + doi="10.17487/RFC0155", + } + +@misc{rfc156, + author="J. Bouknight", + title="{Status of the Illinois site: Response to RFC 116}", + howpublished="RFC 156", + series="Internet Request for Comments", + type="RFC", + number="156", + pages="1--1", + year=1971, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc156.txt", + key="RFC 156", + doi="10.17487/RFC0156", + } + +@misc{rfc157, + author="V.G. Cerf", + title="{Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems}", + howpublished="RFC 157", + series="Internet Request for Comments", + type="RFC", + number="157", + pages="1--2", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc157.txt", + key="RFC 157", + doi="10.17487/RFC0157", + } + +@misc{rfc158, + author="T.C. O'Sullivan", + title="{Telnet Protocol: A Proposed Document}", + howpublished="RFC 158", + series="Internet Request for Comments", + type="RFC", + number="158", + pages="1--11", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 495, updated by RFC 318", +url="https://www.rfc-editor.org/rfc/rfc158.txt", + key="RFC 158", + doi="10.17487/RFC0158", + } + +@misc{rfc160, + author="Network Information Center. Stanford Research Institute", + title="{RFC brief list}", + howpublished="RFC 160", + series="Internet Request for Comments", + type="RFC", + number="160", + pages="1--4", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 200, 999", +url="https://www.rfc-editor.org/rfc/rfc160.txt", + key="RFC 160", + doi="10.17487/RFC0160", + } + +@misc{rfc161, + author="A. Shoshani", + title="{Solution to the race condition in the ICP}", + howpublished="RFC 161", + series="Internet Request for Comments", + type="RFC", + number="161", + pages="1--1", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc161.txt", + key="RFC 161", + doi="10.17487/RFC0161", + } + +@misc{rfc162, + author="M. Kampe", + title="{NETBUGGER3}", + howpublished="RFC 162", + series="Internet Request for Comments", + type="RFC", + number="162", + pages="1--2", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc162.txt", + key="RFC 162", + doi="10.17487/RFC0162", + } + +@misc{rfc163, + author="V.G. Cerf", + title="{Data transfer protocols}", + howpublished="RFC 163", + series="Internet Request for Comments", + type="RFC", + number="163", + pages="1--3", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc163.txt", + key="RFC 163", + keywords="FTP, DTP, data, manager", + doi="10.17487/RFC0163", + } + +@misc{rfc164, + author="J.F. Heafner", + title="{Minutes of Network Working Group meeting, 5/16 through 5/19/71}", + howpublished="RFC 164", + series="Internet Request for Comments", + type="RFC", + number="164", + pages="1--32", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc164.txt", + key="RFC 164", + doi="10.17487/RFC0164", + } + +@misc{rfc165, + author="J. Postel", + title="{Proffered Official Initial Connection Protocol}", + howpublished="RFC 165", + series="Internet Request for Comments", + type="RFC", + number="165", + pages="1--5", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC NaN", +url="https://www.rfc-editor.org/rfc/rfc165.txt", + key="RFC 165", + doi="10.17487/RFC0165", + } + +@misc{rfc166, + author="R.H. Anderson and V.G. Cerf and E. Harslem and J.F. Heafner and J. Madden and R.M. Metcalfe and A. Shoshani and J.E. White and D.C.M. Wood", + title="{Data Reconfiguration Service: An implementation specification}", + howpublished="RFC 166", + series="Internet Request for Comments", + type="RFC", + number="166", + pages="1--20", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc166.txt", + key="RFC 166", + doi="10.17487/RFC0166", + } + +@misc{rfc167, + author="A.K. Bhushan and R.M. Metcalfe and J.M. Winett", + title="{Socket conventions reconsidered}", + howpublished="RFC 167", + series="Internet Request for Comments", + type="RFC", + number="167", + pages="1--4", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc167.txt", + key="RFC 167", + doi="10.17487/RFC0167", + } + +@misc{rfc168, + author="J.B. North", + title="{ARPA Network mailing lists}", + howpublished="RFC 168", + series="Internet Request for Comments", + type="RFC", + number="168", + pages="1--7", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 211", +url="https://www.rfc-editor.org/rfc/rfc168.txt", + key="RFC 168", + doi="10.17487/RFC0168", + } + +@misc{rfc169, + author="S.D. Crocker", + title="{COMPUTER NETWORKS}", + howpublished="RFC 169", + series="Internet Request for Comments", + type="RFC", + number="169", + pages="1--4", + year=1971, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc169.txt", + key="RFC 169", + doi="10.17487/RFC0169", + } + +@misc{rfc170, + author="Network Information Center. Stanford Research Institute", + title="{RFC List by Number}", + howpublished="RFC 170", + series="Internet Request for Comments", + type="RFC", + number="170", + pages="1--6", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 200", +url="https://www.rfc-editor.org/rfc/rfc170.txt", + key="RFC 170", + doi="10.17487/RFC0170", + } + +@misc{rfc171, + author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenize and J. Melvin and B. Sundberg and D. Watson and J. White", + title="{The Data Transfer Protocol}", + howpublished="RFC 171", + series="Internet Request for Comments", + type="RFC", + number="171", + pages="1--9", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 264, updated by RFC 238", +url="https://www.rfc-editor.org/rfc/rfc171.txt", + key="RFC 171", + keywords="FTP, DTP", + doi="10.17487/RFC0171", + } + +@misc{rfc172, + author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenzie and J. Melvin and B. Sundberg and D. Watson and J. White", + title="{The File Transfer Protocol}", + howpublished="RFC 172", + series="Internet Request for Comments", + type="RFC", + number="172", + pages="1--12", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 265, updated by RFC 238", +url="https://www.rfc-editor.org/rfc/rfc172.txt", + key="RFC 172", + keywords="FTP", + doi="10.17487/RFC0172", + } + +@misc{rfc173, + author="P.M. Karp and D.B. McKay", + title="{Network Data Management Committee Meeting Announcement}", + howpublished="RFC 173", + series="Internet Request for Comments", + type="RFC", + number="173", + pages="1--2", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc173.txt", + key="RFC 173", + doi="10.17487/RFC0173", + } + +@misc{rfc174, + author="J. Postel and V.G. Cerf", + title="{UCLA - Computer Science Graphics Overview}", + howpublished="RFC 174", + series="Internet Request for Comments", + type="RFC", + number="174", + pages="1--3", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc174.txt", + key="RFC 174", + doi="10.17487/RFC0174", + } + +@misc{rfc175, + author="E. Harslem and J.F. Heafner", + title="{Comments on ``Socket Conventions Reconsidered''}", + howpublished="RFC 175", + series="Internet Request for Comments", + type="RFC", + number="175", + pages="1--1", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc175.txt", + key="RFC 175", + doi="10.17487/RFC0175", + } + +@misc{rfc176, + author="A.K. Bhushan and R. Kanodia and R.M. Metcalfe and J. Postel", + title="{Comments on ``Byte size for connections''}", + howpublished="RFC 176", + series="Internet Request for Comments", + type="RFC", + number="176", + pages="1--5", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc176.txt", + key="RFC 176", + doi="10.17487/RFC0176", + } + +@misc{rfc177, + author="J. McConnell", + title="{Device independent graphical display description}", + howpublished="RFC 177", + series="Internet Request for Comments", + type="RFC", + number="177", + pages="1--9", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 181", +url="https://www.rfc-editor.org/rfc/rfc177.txt", + key="RFC 177", + doi="10.17487/RFC0177", + } + +@misc{rfc178, + author="I.W. Cotton", + title="{Network graphic attention handling}", + howpublished="RFC 178", + series="Internet Request for Comments", + type="RFC", + number="178", + pages="1--11", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc178.txt", + key="RFC 178", + doi="10.17487/RFC0178", + } + +@misc{rfc179, + author="A.M. McKenzie", + title="{Link Number Assignments}", + howpublished="RFC 179", + series="Internet Request for Comments", + type="RFC", + number="179", + pages="1--1", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc179.txt", + key="RFC 179", + doi="10.17487/RFC0179", + } + +@misc{rfc180, + author="A.M. McKenzie", + title="{File system questionnaire}", + howpublished="RFC 180", + series="Internet Request for Comments", + type="RFC", + number="180", + pages="1--4", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc180.txt", + key="RFC 180", + doi="10.17487/RFC0180", + } + +@misc{rfc181, + author="J. McConnell", + title="{Modifications to RFC 177}", + howpublished="RFC 181", + series="Internet Request for Comments", + type="RFC", + number="181", + pages="1--3", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc181.txt", + key="RFC 181", + doi="10.17487/RFC0181", + } + +@misc{rfc182, + author="J.B. North", + title="{Compilation of list of relevant site reports}", + howpublished="RFC 182", + series="Internet Request for Comments", + type="RFC", + number="182", + pages="1--1", + year=1971, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc182.txt", + key="RFC 182", + doi="10.17487/RFC0182", + } + +@misc{rfc183, + author="J.M. Winett", + title="{EBCDIC Codes and Their Mapping to ASCII}", + howpublished="RFC 183", + series="Internet Request for Comments", + type="RFC", + number="183", + pages="1--12", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc183.txt", + key="RFC 183", + doi="10.17487/RFC0183", + } + +@misc{rfc184, + author="K.C. Kelley", + title="{Proposed graphic display modes}", + howpublished="RFC 184", + series="Internet Request for Comments", + type="RFC", + number="184", + pages="1--7", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc184.txt", + key="RFC 184", + doi="10.17487/RFC0184", + } + +@misc{rfc185, + author="J.B. North", + title="{NIC distribution of manuals and handbooks}", + howpublished="RFC 185", + series="Internet Request for Comments", + type="RFC", + number="185", + pages="1--1", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc185.txt", + key="RFC 185", + doi="10.17487/RFC0185", + } + +@misc{rfc186, + author="J.C. Michener", + title="{Network graphics loader}", + howpublished="RFC 186", + series="Internet Request for Comments", + type="RFC", + number="186", + pages="1--17", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc186.txt", + key="RFC 186", + doi="10.17487/RFC0186", + } + +@misc{rfc187, + author="D.B. McKay and D.P. Karp", + title="{Network/440 Protocol Concept}", + howpublished="RFC 187", + series="Internet Request for Comments", + type="RFC", + number="187", + pages="1--11", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc187.txt", + key="RFC 187", + doi="10.17487/RFC0187", + } + +@misc{rfc188, + author="P.M. Karp and D.B. McKay", + title="{Data management meeting announcement}", + howpublished="RFC 188", + series="Internet Request for Comments", + type="RFC", + number="188", + pages="1--2", + year=1971, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc188.txt", + key="RFC 188", + doi="10.17487/RFC0188", + } + +@misc{rfc189, + author="R.T. Braden", + title="{Interim NETRJS specifications}", + howpublished="RFC 189", + series="Internet Request for Comments", + type="RFC", + number="189", + pages="1--19", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 599, updated by RFC 283", +url="https://www.rfc-editor.org/rfc/rfc189.txt", + key="RFC 189", + doi="10.17487/RFC0189", + } + +@misc{rfc190, + author="L.P. Deutsch", + title="{DEC PDP-10-IMLAC communications system}", + howpublished="RFC 190", + series="Internet Request for Comments", + type="RFC", + number="190", + pages="1--16", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc190.txt", + key="RFC 190", + doi="10.17487/RFC0190", + } + +@misc{rfc191, + author="C.H. Irby", + title="{Graphics implementation and conceptualization at Augmentation Research Center}", + howpublished="RFC 191", + series="Internet Request for Comments", + type="RFC", + number="191", + pages="1--4", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc191.txt", + key="RFC 191", + doi="10.17487/RFC0191", + } + +@misc{rfc192, + author="R.W. Watson", + title="{Some factors which a Network Graphics Protocol must consider}", + howpublished="RFC 192", + series="Internet Request for Comments", + type="RFC", + number="192", + pages="1--19", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc192.txt", + key="RFC 192", + doi="10.17487/RFC0192", + } + +@misc{rfc193, + author="E. Harslem and J.F. Heafner", + title="{NETWORK CHECKOUT}", + howpublished="RFC 193", + series="Internet Request for Comments", + type="RFC", + number="193", + pages="1--2", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 198, updated by RFC 198", +url="https://www.rfc-editor.org/rfc/rfc193.txt", + key="RFC 193", + doi="10.17487/RFC0193", + } + +@misc{rfc194, + author="V. Cerf and E. Harslem and J. Heafner and B. Metcalfe and J. White", + title="{The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes}", + howpublished="RFC 194", + series="Internet Request for Comments", + type="RFC", + number="194", + pages="1--18", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc194.txt", + key="RFC 194", + doi="10.17487/RFC0194", + } + +@misc{rfc195, + author="G.H. Mealy", + title="{Data computers-data descriptions and access language}", + howpublished="RFC 195", + series="Internet Request for Comments", + type="RFC", + number="195", + pages="1--4", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc195.txt", + key="RFC 195", + doi="10.17487/RFC0195", + } + +@misc{rfc196, + author="R.W. Watson", + title="{Mail Box Protocol}", + howpublished="RFC 196", + series="Internet Request for Comments", + type="RFC", + number="196", + pages="1--4", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 221", +url="https://www.rfc-editor.org/rfc/rfc196.txt", + key="RFC 196", + doi="10.17487/RFC0196", + } + +@misc{rfc197, + author="A. Shoshani and E. Harslem", + title="{Initial Connection Protocol - Reviewed}", + howpublished="RFC 197", + series="Internet Request for Comments", + type="RFC", + number="197", + pages="1--5", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc197.txt", + key="RFC 197", + doi="10.17487/RFC0197", + } + +@misc{rfc198, + author="J.F. Heafner", + title="{Site Certification - Lincoln Labs 360/67}", + howpublished="RFC 198", + series="Internet Request for Comments", + type="RFC", + number="198", + pages="1--1", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 214", +url="https://www.rfc-editor.org/rfc/rfc198.txt", + key="RFC 198", + doi="10.17487/RFC0198", + } + +@misc{rfc199, + author="T. Williams", + title="{Suggestions for a Network Data-Tablet Graphics Protocol}", + howpublished="RFC 199", + series="Internet Request for Comments", + type="RFC", + number="199", + pages="1--10", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc199.txt", + key="RFC 199", + doi="10.17487/RFC0199", + } + +@misc{rfc200, + author="J.B. North", + title="{RFC list by number}", + howpublished="RFC 200", + series="Internet Request for Comments", + type="RFC", + number="200", + pages="1--7", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC NaN", +url="https://www.rfc-editor.org/rfc/rfc200.txt", + key="RFC 200", + doi="10.17487/RFC0200", + } + +@misc{rfc202, + author="S.M. Wolfe and J. Postel", + title="{Possible Deadlock in ICP}", + howpublished="RFC 202", + series="Internet Request for Comments", + type="RFC", + number="202", + pages="1--2", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc202.txt", + key="RFC 202", + doi="10.17487/RFC0202", + } + +@misc{rfc203, + author="R.B. Kalin", + title="{Achieving reliable communication}", + howpublished="RFC 203", + series="Internet Request for Comments", + type="RFC", + number="203", + pages="1--4", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc203.txt", + key="RFC 203", + doi="10.17487/RFC0203", + } + +@misc{rfc204, + author="J. Postel", + title="{Sockets in use}", + howpublished="RFC 204", + series="Internet Request for Comments", + type="RFC", + number="204", + pages="1--1", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 234", +url="https://www.rfc-editor.org/rfc/rfc204.txt", + key="RFC 204", + doi="10.17487/RFC0204", + } + +@misc{rfc205, + author="R.T. Braden", + title="{NETCRT - a character display protocol}", + howpublished="RFC 205", + series="Internet Request for Comments", + type="RFC", + number="205", + pages="1--13", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc205.txt", + key="RFC 205", + doi="10.17487/RFC0205", + } + +@misc{rfc206, + author="J. White", + title="{A User TELNET Description of an Initial Implementation}", + howpublished="RFC 206", + series="Internet Request for Comments", + type="RFC", + number="206", + pages="1--14", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc206.txt", + key="RFC 206", + doi="10.17487/RFC0206", + } + +@misc{rfc207, + author="A. Vezza", + title="{September Network Working Group meeting}", + howpublished="RFC 207", + series="Internet Request for Comments", + type="RFC", + number="207", + pages="1--2", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 212", +url="https://www.rfc-editor.org/rfc/rfc207.txt", + key="RFC 207", + doi="10.17487/RFC0207", + } + +@misc{rfc208, + author="A.M. McKenzie", + title="{Address tables}", + howpublished="RFC 208", + series="Internet Request for Comments", + type="RFC", + number="208", + pages="1--3", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc208.txt", + key="RFC 208", + doi="10.17487/RFC0208", + } + +@misc{rfc209, + author="B. Cosell", + title="{Host/IMP interface documentation}", + howpublished="RFC 209", + series="Internet Request for Comments", + type="RFC", + number="209", + pages="1--1", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc209.txt", + key="RFC 209", + doi="10.17487/RFC0209", + } + +@misc{rfc210, + author="W. Conrad", + title="{Improvement of Flow Control}", + howpublished="RFC 210", + series="Internet Request for Comments", + type="RFC", + number="210", + pages="1--2", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc210.txt", + key="RFC 210", + doi="10.17487/RFC0210", + } + +@misc{rfc211, + author="J.B. North", + title="{ARPA Network Mailing Lists}", + howpublished="RFC 211", + series="Internet Request for Comments", + type="RFC", + number="211", + pages="1--13", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 300", +url="https://www.rfc-editor.org/rfc/rfc211.txt", + key="RFC 211", + doi="10.17487/RFC0211", + } + +@misc{rfc212, + author="Information Sciences Institute University of Southern California", + title="{NWG meeting on network usage}", + howpublished="RFC 212", + series="Internet Request for Comments", + type="RFC", + number="212", + pages="1--2", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 222", +url="https://www.rfc-editor.org/rfc/rfc212.txt", + key="RFC 212", + doi="10.17487/RFC0212", + } + +@misc{rfc213, + author="B. Cosell", + title="{IMP System change notification}", + howpublished="RFC 213", + series="Internet Request for Comments", + type="RFC", + number="213", + pages="1--1", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc213.txt", + key="RFC 213", + doi="10.17487/RFC0213", + } + +@misc{rfc214, + author="E. Harslem", + title="{Network checkpoint}", + howpublished="RFC 214", + series="Internet Request for Comments", + type="RFC", + number="214", + pages="1--2", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc214.txt", + key="RFC 214", + doi="10.17487/RFC0214", + } + +@misc{rfc215, + author="A.M. McKenzie", + title="{NCP, ICP, and Telnet: The Terminal IMP implementation}", + howpublished="RFC 215", + series="Internet Request for Comments", + type="RFC", + number="215", + pages="1--7", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc215.txt", + key="RFC 215", + doi="10.17487/RFC0215", + } + +@misc{rfc216, + author="J.E. White", + title="{Telnet Access to UCSB's On-Line System}", + howpublished="RFC 216", + series="Internet Request for Comments", + type="RFC", + number="216", + pages="1--16", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc216.txt", + key="RFC 216", + doi="10.17487/RFC0216", + } + +@misc{rfc217, + author="J.E. White", + title="{Specifications changes for OLS, RJE/RJOR, and SMFS}", + howpublished="RFC 217", + series="Internet Request for Comments", + type="RFC", + number="217", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc217.txt", + key="RFC 217", + doi="10.17487/RFC0217", + } + +@misc{rfc218, + author="B. Cosell", + title="{Changing the IMP status reporting facility}", + howpublished="RFC 218", + series="Internet Request for Comments", + type="RFC", + number="218", + pages="1--1", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc218.txt", + key="RFC 218", + doi="10.17487/RFC0218", + } + +@misc{rfc219, + author="R. Winter", + title="{User's View of the Datacomputer}", + howpublished="RFC 219", + series="Internet Request for Comments", + type="RFC", + number="219", + pages="1--7", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc219.txt", + key="RFC 219", + doi="10.17487/RFC0219", + } + +@misc{rfc221, + author="R.W. Watson", + title="{Mail Box Protocol: Version 2}", + howpublished="RFC 221", + series="Internet Request for Comments", + type="RFC", + number="221", + pages="1--5", + year=1971, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 278", +url="https://www.rfc-editor.org/rfc/rfc221.txt", + key="RFC 221", + doi="10.17487/RFC0221", + } + +@misc{rfc222, + author="R.M. Metcalfe", + title="{Subject: System programmer's workshop}", + howpublished="RFC 222", + series="Internet Request for Comments", + type="RFC", + number="222", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 234", +url="https://www.rfc-editor.org/rfc/rfc222.txt", + key="RFC 222", + doi="10.17487/RFC0222", + } + +@misc{rfc223, + author="J.T. Melvin and R.W. Watson", + title="{Network Information Center schedule for network users}", + howpublished="RFC 223", + series="Internet Request for Comments", + type="RFC", + number="223", + pages="1--4", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc223.txt", + key="RFC 223", + doi="10.17487/RFC0223", + } + +@misc{rfc224, + author="A.M. McKenzie", + title="{Comments on Mailbox Protocol}", + howpublished="RFC 224", + series="Internet Request for Comments", + type="RFC", + number="224", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc224.txt", + key="RFC 224", + doi="10.17487/RFC0224", + } + +@misc{rfc225, + author="E. Harslem and R. Stoughton", + title="{Rand/UCSB network graphics experiment}", + howpublished="RFC 225", + series="Internet Request for Comments", + type="RFC", + number="225", + pages="1--5", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc225.txt", + key="RFC 225", + doi="10.17487/RFC0225", + } + +@misc{rfc226, + author="P.M. Karp", + title="{Standardization of host mnemonics}", + howpublished="RFC 226", + series="Internet Request for Comments", + type="RFC", + number="226", + pages="1--1", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 247", +url="https://www.rfc-editor.org/rfc/rfc226.txt", + key="RFC 226", + doi="10.17487/RFC0226", + } + +@misc{rfc227, + author="J.F. Heafner and E. Harslem", + title="{Data transfer rates (Rand/UCLA)}", + howpublished="RFC 227", + series="Internet Request for Comments", + type="RFC", + number="227", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc227.txt", + key="RFC 227", + doi="10.17487/RFC0227", + } + +@misc{rfc228, + author="D.C. Walden", + title="{Clarification}", + howpublished="RFC 228", + series="Internet Request for Comments", + type="RFC", + number="228", + pages="1--1", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc228.txt", + key="RFC 228", + doi="10.17487/RFC0228", + } + +@misc{rfc229, + author="J. Postel", + title="{Standard host names}", + howpublished="RFC 229", + series="Internet Request for Comments", + type="RFC", + number="229", + pages="1--3", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 236", +url="https://www.rfc-editor.org/rfc/rfc229.txt", + key="RFC 229", + doi="10.17487/RFC0229", + } + +@misc{rfc230, + author="T. Pyke", + title="{Toward reliable operation of minicomputer-based terminals on a TIP}", + howpublished="RFC 230", + series="Internet Request for Comments", + type="RFC", + number="230", + pages="1--3", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc230.txt", + key="RFC 230", + doi="10.17487/RFC0230", + } + +@misc{rfc231, + author="J.F. Heafner and E. Harslem", + title="{Service center standards for remote usage: A user's view}", + howpublished="RFC 231", + series="Internet Request for Comments", + type="RFC", + number="231", + pages="1--4", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc231.txt", + key="RFC 231", + doi="10.17487/RFC0231", + } + +@misc{rfc232, + author="A. Vezza", + title="{Postponement of network graphics meeting}", + howpublished="RFC 232", + series="Internet Request for Comments", + type="RFC", + number="232", + pages="1--1", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc232.txt", + key="RFC 232", + doi="10.17487/RFC0232", + } + +@misc{rfc233, + author="A. Bhushan and R. Metcalfe", + title="{Standardization of host call letters}", + howpublished="RFC 233", + series="Internet Request for Comments", + type="RFC", + number="233", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc233.txt", + key="RFC 233", + doi="10.17487/RFC0233", + } + +@misc{rfc234, + author="A. Vezza", + title="{Network Working Group meeting schedule}", + howpublished="RFC 234", + series="Internet Request for Comments", + type="RFC", + number="234", + pages="1--1", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc234.txt", + key="RFC 234", + doi="10.17487/RFC0234", + } + +@misc{rfc235, + author="E. Westheimer", + title="{Site status}", + howpublished="RFC 235", + series="Internet Request for Comments", + type="RFC", + number="235", + pages="1--5", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 240", +url="https://www.rfc-editor.org/rfc/rfc235.txt", + key="RFC 235", + doi="10.17487/RFC0235", + } + +@misc{rfc236, + author="J. Postel", + title="{Standard host names}", + howpublished="RFC 236", + series="Internet Request for Comments", + type="RFC", + number="236", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc236.txt", + key="RFC 236", + doi="10.17487/RFC0236", + } + +@misc{rfc237, + author="R.W. Watson", + title="{NIC view of standard host names}", + howpublished="RFC 237", + series="Internet Request for Comments", + type="RFC", + number="237", + pages="1--1", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 273", +url="https://www.rfc-editor.org/rfc/rfc237.txt", + key="RFC 237", + doi="10.17487/RFC0237", + } + +@misc{rfc238, + author="R.T. Braden", + title="{Comments on DTP and FTP proposals}", + howpublished="RFC 238", + series="Internet Request for Comments", + type="RFC", + number="238", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc238.txt", + key="RFC 238", + keywords="FTP", + doi="10.17487/RFC0238", + } + +@misc{rfc239, + author="R.T. Braden", + title="{Host mnemonics proposed in RFC 226 (NIC 7625)}", + howpublished="RFC 239", + series="Internet Request for Comments", + type="RFC", + number="239", + pages="1--1", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc239.txt", + key="RFC 239", + doi="10.17487/RFC0239", + } + +@misc{rfc240, + author="A.M. McKenzie", + title="{Site Status}", + howpublished="RFC 240", + series="Internet Request for Comments", + type="RFC", + number="240", + pages="1--4", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 252", +url="https://www.rfc-editor.org/rfc/rfc240.txt", + key="RFC 240", + doi="10.17487/RFC0240", + } + +@misc{rfc241, + author="A.M. McKenzie", + title="{Connecting computers to MLC ports}", + howpublished="RFC 241", + series="Internet Request for Comments", + type="RFC", + number="241", + pages="1--2", + year=1971, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc241.txt", + key="RFC 241", + doi="10.17487/RFC0241", + } + +@misc{rfc242, + author="L. Haibt and A.P. Mullery", + title="{Data Descriptive Language for Shared Data}", + howpublished="RFC 242", + series="Internet Request for Comments", + type="RFC", + number="242", + pages="1--10", + year=1971, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc242.txt", + key="RFC 242", + doi="10.17487/RFC0242", + } + +@misc{rfc243, + author="A.P. Mullery", + title="{Network and data sharing bibliography}", + howpublished="RFC 243", + series="Internet Request for Comments", + type="RFC", + number="243", + pages="1--7", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 290", +url="https://www.rfc-editor.org/rfc/rfc243.txt", + key="RFC 243", + doi="10.17487/RFC0243", + } + +@misc{rfc245, + author="C. Falls", + title="{Reservations for Network Group meeting}", + howpublished="RFC 245", + series="Internet Request for Comments", + type="RFC", + number="245", + pages="1--1", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc245.txt", + key="RFC 245", + doi="10.17487/RFC0245", + } + +@misc{rfc246, + author="A. Vezza", + title="{Network Graphics meeting}", + howpublished="RFC 246", + series="Internet Request for Comments", + type="RFC", + number="246", + pages="1--1", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc246.txt", + key="RFC 246", + doi="10.17487/RFC0246", + } + +@misc{rfc247, + author="P.M. Karp", + title="{Proffered set of standard host names}", + howpublished="RFC 247", + series="Internet Request for Comments", + type="RFC", + number="247", + pages="1--4", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc247.txt", + key="RFC 247", + doi="10.17487/RFC0247", + } + +@misc{rfc249, + author="R.F. Borelli", + title="{Coordination of equipment and supplies purchase}", + howpublished="RFC 249", + series="Internet Request for Comments", + type="RFC", + number="249", + pages="1--2", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc249.txt", + key="RFC 249", + doi="10.17487/RFC0249", + } + +@misc{rfc250, + author="H. Brodie", + title="{Some thoughts on file transfer}", + howpublished="RFC 250", + series="Internet Request for Comments", + type="RFC", + number="250", + pages="1--1", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc250.txt", + key="RFC 250", + doi="10.17487/RFC0250", + } + +@misc{rfc251, + author="D. Stern", + title="{Weather data}", + howpublished="RFC 251", + series="Internet Request for Comments", + type="RFC", + number="251", + pages="1--2", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc251.txt", + key="RFC 251", + doi="10.17487/RFC0251", + } + +@misc{rfc252, + author="E. Westheimer", + title="{Network host status}", + howpublished="RFC 252", + series="Internet Request for Comments", + type="RFC", + number="252", + pages="1--3", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 255", +url="https://www.rfc-editor.org/rfc/rfc252.txt", + key="RFC 252", + doi="10.17487/RFC0252", + } + +@misc{rfc253, + author="J.A. Moorer", + title="{Second Network Graphics meeting details}", + howpublished="RFC 253", + series="Internet Request for Comments", + type="RFC", + number="253", + pages="1--1", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc253.txt", + key="RFC 253", + doi="10.17487/RFC0253", + } + +@misc{rfc254, + author="A. Bhushan", + title="{Scenarios for using ARPANET computers}", + howpublished="RFC 254", + series="Internet Request for Comments", + type="RFC", + number="254", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc254.txt", + key="RFC 254", + doi="10.17487/RFC0254", + } + +@misc{rfc255, + author="E. Westheimer", + title="{Status of network hosts}", + howpublished="RFC 255", + series="Internet Request for Comments", + type="RFC", + number="255", + pages="1--2", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 266", +url="https://www.rfc-editor.org/rfc/rfc255.txt", + key="RFC 255", + doi="10.17487/RFC0255", + } + +@misc{rfc256, + author="B. Cosell", + title="{IMPSYS change notification}", + howpublished="RFC 256", + series="Internet Request for Comments", + type="RFC", + number="256", + pages="1--1", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc256.txt", + key="RFC 256", + doi="10.17487/RFC0256", + } + +@misc{rfc263, + author="A.M. McKenzie", + title="{``Very Distant'' Host interface}", + howpublished="RFC 263", + series="Internet Request for Comments", + type="RFC", + number="263", + pages="1--2", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc263.txt", + key="RFC 263", + doi="10.17487/RFC0263", + } + +@misc{rfc264, + author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenize and B. Sundberg and D. Watson and J. White", + title="{The Data Transfer Protocol}", + howpublished="RFC 264", + series="Internet Request for Comments", + type="RFC", + number="264", + pages="1--9", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 354, updated by RFC 310", +url="https://www.rfc-editor.org/rfc/rfc264.txt", + key="RFC 264", + keywords="FTP, DTP", + doi="10.17487/RFC0264", + } + +@misc{rfc265, + author="A. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner and A. McKenzie and J. Melvin and B. Sundberg and D. Watson and J. White", + title="{The File Transfer Protocol}", + howpublished="RFC 265", + series="Internet Request for Comments", + type="RFC", + number="265", + pages="1--12", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 354, updated by RFCs 281, 294, 310", +url="https://www.rfc-editor.org/rfc/rfc265.txt", + key="RFC 265", + keywords="FTP", + doi="10.17487/RFC0265", + } + +@misc{rfc266, + author="E. Westheimer", + title="{Network host status}", + howpublished="RFC 266", + series="Internet Request for Comments", + type="RFC", + number="266", + pages="1--2", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 267", +url="https://www.rfc-editor.org/rfc/rfc266.txt", + key="RFC 266", + doi="10.17487/RFC0266", + } + +@misc{rfc267, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 267", + series="Internet Request for Comments", + type="RFC", + number="267", + pages="1--4", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 287", +url="https://www.rfc-editor.org/rfc/rfc267.txt", + key="RFC 267", + doi="10.17487/RFC0267", + } + +@misc{rfc268, + author="J. Postel", + title="{Graphics facilities information}", + howpublished="RFC 268", + series="Internet Request for Comments", + type="RFC", + number="268", + pages="1--1", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc268.txt", + key="RFC 268", + doi="10.17487/RFC0268", + } + +@misc{rfc269, + author="H. Brodie", + title="{Some Experience with File Transfer}", + howpublished="RFC 269", + series="Internet Request for Comments", + type="RFC", + number="269", + pages="1--3", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc269.txt", + key="RFC 269", + doi="10.17487/RFC0269", + } + +@misc{rfc270, + author="A.M. McKenzie", + title="{Correction to BBN Report No. 1822 (NIC NO 7958)}", + howpublished="RFC 270", + series="Internet Request for Comments", + type="RFC", + number="270", + pages="1--1", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc270.txt", + key="RFC 270", + doi="10.17487/RFC0270", + } + +@misc{rfc271, + author="B. Cosell", + title="{IMP System change notifications}", + howpublished="RFC 271", + series="Internet Request for Comments", + type="RFC", + number="271", + pages="1--2", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc271.txt", + key="RFC 271", + doi="10.17487/RFC0271", + } + +@misc{rfc273, + author="R.W. Watson", + title="{More on standard host names}", + howpublished="RFC 273", + series="Internet Request for Comments", + type="RFC", + number="273", + pages="1--3", + year=1971, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc273.txt", + key="RFC 273", + doi="10.17487/RFC0273", + } + +@misc{rfc274, + author="E. Forman", + title="{Establishing a local guide for network usage}", + howpublished="RFC 274", + series="Internet Request for Comments", + type="RFC", + number="274", + pages="1--5", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc274.txt", + key="RFC 274", + doi="10.17487/RFC0274", + } + +@misc{rfc276, + author="R.W. Watson", + title="{NIC course}", + howpublished="RFC 276", + series="Internet Request for Comments", + type="RFC", + number="276", + pages="1--1", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc276.txt", + key="RFC 276", + doi="10.17487/RFC0276", + } + +@misc{rfc278, + author="A.K. Bhushan and R.T. Braden and E. Harslem and J.F. Heafner and A.M. McKenzie and J.T. Melvin and R.L. Sundberg and R.W. Watson and J.E. White", + title="{Revision of the Mail Box Protocol}", + howpublished="RFC 278", + series="Internet Request for Comments", + type="RFC", + number="278", + pages="1--4", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc278.txt", + key="RFC 278", + doi="10.17487/RFC0278", + } + +@misc{rfc280, + author="R.W. Watson", + title="{A Draft of Host Names}", + howpublished="RFC 280", + series="Internet Request for Comments", + type="RFC", + number="280", + pages="1--3", + year=1971, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc280.txt", + key="RFC 280", + doi="10.17487/RFC0280", + } + +@misc{rfc281, + author="A.M. McKenzie", + title="{Suggested addition to File Transfer Protocol}", + howpublished="RFC 281", + series="Internet Request for Comments", + type="RFC", + number="281", + pages="1--8", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc281.txt", + key="RFC 281", + keywords="FTP", + doi="10.17487/RFC0281", + } + +@misc{rfc282, + author="M.A. Padlipsky", + title="{Graphics meeting report}", + howpublished="RFC 282", + series="Internet Request for Comments", + type="RFC", + number="282", + pages="1--8", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc282.txt", + key="RFC 282", + doi="10.17487/RFC0282", + } + +@misc{rfc283, + author="R.T. Braden", + title="{NETRJT: Remote Job Service Protocol for TIPS}", + howpublished="RFC 283", + series="Internet Request for Comments", + type="RFC", + number="283", + pages="1--9", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc283.txt", + key="RFC 283", + doi="10.17487/RFC0283", + } + +@misc{rfc285, + author="D. Huff", + title="{Network graphics}", + howpublished="RFC 285", + series="Internet Request for Comments", + type="RFC", + number="285", + pages="1--8", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc285.txt", + key="RFC 285", + doi="10.17487/RFC0285", + } + +@misc{rfc286, + author="E. Forman", + title="{Network Library Information System}", + howpublished="RFC 286", + series="Internet Request for Comments", + type="RFC", + number="286", + pages="1--1", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc286.txt", + key="RFC 286", + doi="10.17487/RFC0286", + } + +@misc{rfc287, + author="E. Westheimer", + title="{Status of Network Hosts}", + howpublished="RFC 287", + series="Internet Request for Comments", + type="RFC", + number="287", + pages="1--5", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 288", +url="https://www.rfc-editor.org/rfc/rfc287.txt", + key="RFC 287", + doi="10.17487/RFC0287", + } + +@misc{rfc288, + author="E. Westheimer", + title="{Network host status}", + howpublished="RFC 288", + series="Internet Request for Comments", + type="RFC", + number="288", + pages="1--4", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 293, updated by RFC 293", +url="https://www.rfc-editor.org/rfc/rfc288.txt", + key="RFC 288", + doi="10.17487/RFC0288", + } + +@misc{rfc289, + author="R.W. Watson", + title="{What we hope is an official list of host names}", + howpublished="RFC 289", + series="Internet Request for Comments", + type="RFC", + number="289", + pages="1--3", + year=1971, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 384", +url="https://www.rfc-editor.org/rfc/rfc289.txt", + key="RFC 289", + doi="10.17487/RFC0289", + } + +@misc{rfc290, + author="A.P. Mullery", + title="{Computer networks and data sharing: A bibliography}", + howpublished="RFC 290", + series="Internet Request for Comments", + type="RFC", + number="290", + pages="1--15", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc290.txt", + key="RFC 290", + doi="10.17487/RFC0290", + } + +@misc{rfc291, + author="D.B. McKay", + title="{Data Management Meeting Announcement}", + howpublished="RFC 291", + series="Internet Request for Comments", + type="RFC", + number="291", + pages="1--2", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc291.txt", + key="RFC 291", + doi="10.17487/RFC0291", + } + +@misc{rfc292, + author="J.C. Michener and I.W. Cotton and K.C. Kelley and D.E. Liddle and E. Meyer", + title="{Graphics Protocol: Level 0 only}", + howpublished="RFC 292", + series="Internet Request for Comments", + type="RFC", + number="292", + pages="1--10", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 493", +url="https://www.rfc-editor.org/rfc/rfc292.txt", + key="RFC 292", + doi="10.17487/RFC0292", + } + +@misc{rfc293, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 293", + series="Internet Request for Comments", + type="RFC", + number="293", + pages="1--4", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 298", +url="https://www.rfc-editor.org/rfc/rfc293.txt", + key="RFC 293", + doi="10.17487/RFC0293", + } + +@misc{rfc294, + author="A.K. Bhushan", + title="{The Use of ``Set Data Type'' Transaction in File Transfer Protocol}", + howpublished="RFC 294", + series="Internet Request for Comments", + type="RFC", + number="294", + pages="1--2", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc294.txt", + key="RFC 294", + keywords="FTP", + doi="10.17487/RFC0294", + } + +@misc{rfc295, + author="J. Postel", + title="{Report of the Protocol Workshop, 12 October 1971}", + howpublished="RFC 295", + series="Internet Request for Comments", + type="RFC", + number="295", + pages="1--4", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc295.txt", + key="RFC 295", + doi="10.17487/RFC0295", + } + +@misc{rfc296, + author="D.E. Liddle", + title="{DS-1 Display System}", + howpublished="RFC 296", + series="Internet Request for Comments", + type="RFC", + number="296", + pages="1--17", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc296.txt", + key="RFC 296", + doi="10.17487/RFC0296", + } + +@misc{rfc297, + author="D.C. Walden", + title="{TIP Message Buffers}", + howpublished="RFC 297", + series="Internet Request for Comments", + type="RFC", + number="297", + pages="1--2", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc297.txt", + key="RFC 297", + doi="10.17487/RFC0297", + } + +@misc{rfc298, + author="E. Westheimer", + title="{Network host status}", + howpublished="RFC 298", + series="Internet Request for Comments", + type="RFC", + number="298", + pages="1--4", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 306", +url="https://www.rfc-editor.org/rfc/rfc298.txt", + key="RFC 298", + doi="10.17487/RFC0298", + } + +@misc{rfc299, + author="D. Hopkin", + title="{Information Management System}", + howpublished="RFC 299", + series="Internet Request for Comments", + type="RFC", + number="299", + pages="1--1", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc299.txt", + key="RFC 299", + doi="10.17487/RFC0299", + } + +@misc{rfc300, + author="J.B. North", + title="{ARPA Network mailing lists}", + howpublished="RFC 300", + series="Internet Request for Comments", + type="RFC", + number="300", + pages="1--9", + year=1972, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 303", +url="https://www.rfc-editor.org/rfc/rfc300.txt", + key="RFC 300", + doi="10.17487/RFC0300", + } + +@misc{rfc301, + author="R. Alter", + title="{BBN IMP (\#5) and NCC Schedule March 4, 1971}", + howpublished="RFC 301", + series="Internet Request for Comments", + type="RFC", + number="301", + pages="1--1", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc301.txt", + key="RFC 301", + doi="10.17487/RFC0301", + } + +@misc{rfc302, + author="R.F. Bryan", + title="{Exercising The ARPANET}", + howpublished="RFC 302", + series="Internet Request for Comments", + type="RFC", + number="302", + pages="1--3", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc302.txt", + key="RFC 302", + doi="10.17487/RFC0302", + } + +@misc{rfc303, + author="Network Information Center. Stanford Research Institute", + title="{ARPA Network mailing lists}", + howpublished="RFC 303", + series="Internet Request for Comments", + type="RFC", + number="303", + pages="1--11", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 329", +url="https://www.rfc-editor.org/rfc/rfc303.txt", + key="RFC 303", + doi="10.17487/RFC0303", + } + +@misc{rfc304, + author="D.B. McKay", + title="{Data Management System Proposal for the ARPA Network}", + howpublished="RFC 304", + series="Internet Request for Comments", + type="RFC", + number="304", + pages="1--8", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc304.txt", + key="RFC 304", + doi="10.17487/RFC0304", + } + +@misc{rfc305, + author="R. Alter", + title="{Unknown Host Numbers}", + howpublished="RFC 305", + series="Internet Request for Comments", + type="RFC", + number="305", + pages="1--1", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc305.txt", + key="RFC 305", + doi="10.17487/RFC0305", + } + +@misc{rfc306, + author="E. Westheimer", + title="{Network host status}", + howpublished="RFC 306", + series="Internet Request for Comments", + type="RFC", + number="306", + pages="1--4", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 315", +url="https://www.rfc-editor.org/rfc/rfc306.txt", + key="RFC 306", + doi="10.17487/RFC0306", + } + +@misc{rfc307, + author="E. Harslem", + title="{Using network Remote Job Entry}", + howpublished="RFC 307", + series="Internet Request for Comments", + type="RFC", + number="307", + pages="1--6", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc307.txt", + key="RFC 307", + doi="10.17487/RFC0307", + } + +@misc{rfc308, + author="M. Seriff", + title="{ARPANET host availability data}", + howpublished="RFC 308", + series="Internet Request for Comments", + type="RFC", + number="308", + pages="1--4", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc308.txt", + key="RFC 308", + doi="10.17487/RFC0308", + } + +@misc{rfc309, + author="A.K. Bhushan", + title="{Data and File Transfer Workshop Announcement}", + howpublished="RFC 309", + series="Internet Request for Comments", + type="RFC", + number="309", + pages="1--6", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc309.txt", + key="RFC 309", + keywords="FTP, DTP", + doi="10.17487/RFC0309", + } + +@misc{rfc310, + author="A.K. Bhushan", + title="{Another Look at Data and File Transfer Protocols}", + howpublished="RFC 310", + series="Internet Request for Comments", + type="RFC", + number="310", + pages="1--7", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc310.txt", + key="RFC 310", + keywords="FTP", + doi="10.17487/RFC0310", + } + +@misc{rfc311, + author="R.F. Bryan", + title="{New Console Attachments to the USCB Host}", + howpublished="RFC 311", + series="Internet Request for Comments", + type="RFC", + number="311", + pages="1--2", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc311.txt", + key="RFC 311", + doi="10.17487/RFC0311", + } + +@misc{rfc312, + author="A.M. McKenzie", + title="{Proposed Change in IMP-to-Host Protocol}", + howpublished="RFC 312", + series="Internet Request for Comments", + type="RFC", + number="312", + pages="1--2", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc312.txt", + key="RFC 312", + doi="10.17487/RFC0312", + } + +@misc{rfc313, + author="T.C. O'Sullivan", + title="{Computer based instruction}", + howpublished="RFC 313", + series="Internet Request for Comments", + type="RFC", + number="313", + pages="1--8", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc313.txt", + key="RFC 313", + doi="10.17487/RFC0313", + } + +@misc{rfc314, + author="I.W. Cotton", + title="{Network Graphics Working Group Meeting}", + howpublished="RFC 314", + series="Internet Request for Comments", + type="RFC", + number="314", + pages="1--1", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc314.txt", + key="RFC 314", + doi="10.17487/RFC0314", + } + +@misc{rfc315, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 315", + series="Internet Request for Comments", + type="RFC", + number="315", + pages="1--4", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 319", +url="https://www.rfc-editor.org/rfc/rfc315.txt", + key="RFC 315", + doi="10.17487/RFC0315", + } + +@misc{rfc316, + author="D.B. McKay and A.P. Mullery", + title="{ARPA Network Data Management Working Group}", + howpublished="RFC 316", + series="Internet Request for Comments", + type="RFC", + number="316", + pages="1--7", + year=1972, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc316.txt", + key="RFC 316", + doi="10.17487/RFC0316", + } + +@misc{rfc317, + author="J. Postel", + title="{Official Host-Host Protocol Modification: Assigned Link Numbers}", + howpublished="RFC 317", + series="Internet Request for Comments", + type="RFC", + number="317", + pages="1--1", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 604", +url="https://www.rfc-editor.org/rfc/rfc317.txt", + key="RFC 317", + doi="10.17487/RFC0317", + } + +@misc{rfc318, + author="J. Postel", + title="{Telnet Protocols}", + howpublished="RFC 318", + series="Internet Request for Comments", + type="RFC", + number="318", + pages="1--16", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 435", +url="https://www.rfc-editor.org/rfc/rfc318.txt", + key="RFC 318", + doi="10.17487/RFC0318", + } + +@misc{rfc319, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 319", + series="Internet Request for Comments", + type="RFC", + number="319", + pages="1--4", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 326", +url="https://www.rfc-editor.org/rfc/rfc319.txt", + key="RFC 319", + doi="10.17487/RFC0319", + } + +@misc{rfc320, + author="R. Reddy", + title="{Workshop on Hard Copy Line Graphics}", + howpublished="RFC 320", + series="Internet Request for Comments", + type="RFC", + number="320", + pages="1--3", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc320.txt", + key="RFC 320", + doi="10.17487/RFC0320", + } + +@misc{rfc321, + author="P.M. Karp", + title="{CBI Networking Activity at MITRE}", + howpublished="RFC 321", + series="Internet Request for Comments", + type="RFC", + number="321", + pages="1--13", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc321.txt", + key="RFC 321", + doi="10.17487/RFC0321", + } + +@misc{rfc322, + author="V. Cerf and J. Postel", + title="{Well known socket numbers}", + howpublished="RFC 322", + series="Internet Request for Comments", + type="RFC", + number="322", + pages="1--1", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc322.txt", + key="RFC 322", + doi="10.17487/RFC0322", + } + +@misc{rfc323, + author="V. Cerf", + title="{Formation of Network Measurement Group (NMG)}", + howpublished="RFC 323", + series="Internet Request for Comments", + type="RFC", + number="323", + pages="1--9", + year=1972, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 388", +url="https://www.rfc-editor.org/rfc/rfc323.txt", + key="RFC 323", + doi="10.17487/RFC0323", + } + +@misc{rfc324, + author="J. Postel", + title="{RJE Protocol meeting}", + howpublished="RFC 324", + series="Internet Request for Comments", + type="RFC", + number="324", + pages="1--1", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc324.txt", + key="RFC 324", + doi="10.17487/RFC0324", + } + +@misc{rfc325, + author="G. Hicks", + title="{Network Remote Job Entry program - NETRJS}", + howpublished="RFC 325", + series="Internet Request for Comments", + type="RFC", + number="325", + pages="1--9", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc325.txt", + key="RFC 325", + doi="10.17487/RFC0325", + } + +@misc{rfc326, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 326", + series="Internet Request for Comments", + type="RFC", + number="326", + pages="1--4", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 330", +url="https://www.rfc-editor.org/rfc/rfc326.txt", + key="RFC 326", + doi="10.17487/RFC0326", + } + +@misc{rfc327, + author="A.K. Bhushan", + title="{Data and File Transfer workshop notes}", + howpublished="RFC 327", + series="Internet Request for Comments", + type="RFC", + number="327", + pages="1--5", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc327.txt", + key="RFC 327", + doi="10.17487/RFC0327", + } + +@misc{rfc328, + author="J. Postel", + title="{Suggested Telnet Protocol Changes}", + howpublished="RFC 328", + series="Internet Request for Comments", + type="RFC", + number="328", + pages="1--2", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc328.txt", + key="RFC 328", + doi="10.17487/RFC0328", + } + +@misc{rfc329, + author="Network Information Center. Stanford Research Institute", + title="{ARPA Network Mailing Lists}", + howpublished="RFC 329", + series="Internet Request for Comments", + type="RFC", + number="329", + pages="1--13", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 363", +url="https://www.rfc-editor.org/rfc/rfc329.txt", + key="RFC 329", + doi="10.17487/RFC0329", + } + +@misc{rfc330, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 330", + series="Internet Request for Comments", + type="RFC", + number="330", + pages="1--3", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 332", +url="https://www.rfc-editor.org/rfc/rfc330.txt", + key="RFC 330", + doi="10.17487/RFC0330", + } + +@misc{rfc331, + author="J.M. McQuillan", + title="{IMP System Change Notification}", + howpublished="RFC 331", + series="Internet Request for Comments", + type="RFC", + number="331", + pages="1--1", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 343", +url="https://www.rfc-editor.org/rfc/rfc331.txt", + key="RFC 331", + doi="10.17487/RFC0331", + } + +@misc{rfc332, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 332", + series="Internet Request for Comments", + type="RFC", + number="332", + pages="1--4", + year=1972, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 342", +url="https://www.rfc-editor.org/rfc/rfc332.txt", + key="RFC 332", + doi="10.17487/RFC0332", + } + +@misc{rfc333, + author="R.D. Bressler and D. Murphy and D.C. Walden", + title="{Proposed experiment with a Message Switching Protocol}", + howpublished="RFC 333", + series="Internet Request for Comments", + type="RFC", + number="333", + pages="1--26", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc333.txt", + key="RFC 333", + doi="10.17487/RFC0333", + } + +@misc{rfc334, + author="A.M. McKenzie", + title="{Network Use on May 8}", + howpublished="RFC 334", + series="Internet Request for Comments", + type="RFC", + number="334", + pages="1--1", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc334.txt", + key="RFC 334", + doi="10.17487/RFC0334", + } + +@misc{rfc335, + author="R.F. Bryan", + title="{New Interface - IMP/360}", + howpublished="RFC 335", + series="Internet Request for Comments", + type="RFC", + number="335", + pages="1--1", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc335.txt", + key="RFC 335", + doi="10.17487/RFC0335", + } + +@misc{rfc336, + author="I.W. Cotton", + title="{Level 0 Graphic Input Protocol}", + howpublished="RFC 336", + series="Internet Request for Comments", + type="RFC", + number="336", + pages="1--2", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc336.txt", + key="RFC 336", + doi="10.17487/RFC0336", + } + +@misc{rfc338, + author="R.T. Braden", + title="{EBCDIC/ASCII Mapping for Network RJE}", + howpublished="RFC 338", + series="Internet Request for Comments", + type="RFC", + number="338", + pages="1--6", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc338.txt", + key="RFC 338", + doi="10.17487/RFC0338", + } + +@misc{rfc339, + author="R. Thomas", + title="{MLTNET: A ``Multi Telnet'' Subsystem for Tenex}", + howpublished="RFC 339", + series="Internet Request for Comments", + type="RFC", + number="339", + pages="1--4", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc339.txt", + key="RFC 339", + doi="10.17487/RFC0339", + } + +@misc{rfc340, + author="T.C. O'Sullivan", + title="{Proposed Telnet Changes}", + howpublished="RFC 340", + series="Internet Request for Comments", + type="RFC", + number="340", + pages="1--2", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc340.txt", + key="RFC 340", + doi="10.17487/RFC0340", + } + +@misc{rfc342, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 342", + series="Internet Request for Comments", + type="RFC", + number="342", + pages="1--4", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 344", +url="https://www.rfc-editor.org/rfc/rfc342.txt", + key="RFC 342", + doi="10.17487/RFC0342", + } + +@misc{rfc343, + author="A.M. McKenzie", + title="{IMP System change notification}", + howpublished="RFC 343", + series="Internet Request for Comments", + type="RFC", + number="343", + pages="1--2", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 359", +url="https://www.rfc-editor.org/rfc/rfc343.txt", + key="RFC 343", + doi="10.17487/RFC0343", + } + +@misc{rfc344, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 344", + series="Internet Request for Comments", + type="RFC", + number="344", + pages="1--4", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 353", +url="https://www.rfc-editor.org/rfc/rfc344.txt", + key="RFC 344", + doi="10.17487/RFC0344", + } + +@misc{rfc345, + author="K.C. Kelley", + title="{Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN)}", + howpublished="RFC 345", + series="Internet Request for Comments", + type="RFC", + number="345", + pages="1--1", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc345.txt", + key="RFC 345", + keywords="MIP", + doi="10.17487/RFC0345", + } + +@misc{rfc346, + author="J. Postel", + title="{Satellite Considerations}", + howpublished="RFC 346", + series="Internet Request for Comments", + type="RFC", + number="346", + pages="1--1", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc346.txt", + key="RFC 346", + doi="10.17487/RFC0346", + } + +@misc{rfc347, + author="J. Postel", + title="{Echo process}", + howpublished="RFC 347", + series="Internet Request for Comments", + type="RFC", + number="347", + pages="1--1", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc347.txt", + key="RFC 347", + doi="10.17487/RFC0347", + } + +@misc{rfc348, + author="J. Postel", + title="{Discard Process}", + howpublished="RFC 348", + series="Internet Request for Comments", + type="RFC", + number="348", + pages="1--1", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc348.txt", + key="RFC 348", + doi="10.17487/RFC0348", + } + +@misc{rfc349, + author="J. Postel", + title="{Proposed Standard Socket Numbers}", + howpublished="RFC 349", + series="Internet Request for Comments", + type="RFC", + number="349", + pages="1--1", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 433", +url="https://www.rfc-editor.org/rfc/rfc349.txt", + key="RFC 349", + doi="10.17487/RFC0349", + } + +@misc{rfc350, + author="R. Stoughton", + title="{User Accounts for UCSB On-Line System}", + howpublished="RFC 350", + series="Internet Request for Comments", + type="RFC", + number="350", + pages="1--3", + year=1972, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc350.txt", + key="RFC 350", + doi="10.17487/RFC0350", + } + +@misc{rfc351, + author="D. Crocker", + title="{Graphics information form for the ARPANET graphics resources notebook}", + howpublished="RFC 351", + series="Internet Request for Comments", + type="RFC", + number="351", + pages="1--2", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc351.txt", + key="RFC 351", + doi="10.17487/RFC0351", + } + +@misc{rfc352, + author="D. Crocker", + title="{TIP Site Information Form}", + howpublished="RFC 352", + series="Internet Request for Comments", + type="RFC", + number="352", + pages="1--3", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc352.txt", + key="RFC 352", + doi="10.17487/RFC0352", + } + +@misc{rfc353, + author="E. Westheimer", + title="{Network host status}", + howpublished="RFC 353", + series="Internet Request for Comments", + type="RFC", + number="353", + pages="1--5", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 362", +url="https://www.rfc-editor.org/rfc/rfc353.txt", + key="RFC 353", + doi="10.17487/RFC0353", + } + +@misc{rfc354, + author="A.K. Bhushan", + title="{File Transfer Protocol}", + howpublished="RFC 354", + series="Internet Request for Comments", + type="RFC", + number="354", + pages="1--25", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 542, updated by RFCs 385, 454, 683", +url="https://www.rfc-editor.org/rfc/rfc354.txt", + key="RFC 354", + keywords="FTP", + doi="10.17487/RFC0354", + } + +@misc{rfc355, + author="J. Davidson", + title="{Response to NWG/RFC 346}", + howpublished="RFC 355", + series="Internet Request for Comments", + type="RFC", + number="355", + pages="1--3", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc355.txt", + key="RFC 355", + doi="10.17487/RFC0355", + } + +@misc{rfc356, + author="R. Alter", + title="{ARPA Network Control Center}", + howpublished="RFC 356", + series="Internet Request for Comments", + type="RFC", + number="356", + pages="1--1", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc356.txt", + key="RFC 356", + doi="10.17487/RFC0356", + } + +@misc{rfc357, + author="J. Davidson", + title="{Echoing strategy for satellite links}", + howpublished="RFC 357", + series="Internet Request for Comments", + type="RFC", + number="357", + pages="1--13", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc357.txt", + key="RFC 357", + doi="10.17487/RFC0357", + } + +@misc{rfc359, + author="D.C. Walden", + title="{Status of the Release of the New IMP System (2600)}", + howpublished="RFC 359", + series="Internet Request for Comments", + type="RFC", + number="359", + pages="1--1", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc359.txt", + key="RFC 359", + doi="10.17487/RFC0359", + } + +@misc{rfc360, + author="C. Holland", + title="{Proposed Remote Job Entry Protocol}", + howpublished="RFC 360", + series="Internet Request for Comments", + type="RFC", + number="360", + pages="1--18", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 407", +url="https://www.rfc-editor.org/rfc/rfc360.txt", + key="RFC 360", + doi="10.17487/RFC0360", + } + +@misc{rfc361, + author="R.D. Bressler", + title="{Deamon Processes on Host 106}", + howpublished="RFC 361", + series="Internet Request for Comments", + type="RFC", + number="361", + pages="1--1", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc361.txt", + key="RFC 361", + doi="10.17487/RFC0361", + } + +@misc{rfc362, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 362", + series="Internet Request for Comments", + type="RFC", + number="362", + pages="1--4", + year=1972, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 366", +url="https://www.rfc-editor.org/rfc/rfc362.txt", + key="RFC 362", + doi="10.17487/RFC0362", + } + +@misc{rfc363, + author="Network Information Center. Stanford Research Institute", + title="{ARPA Network mailing lists}", + howpublished="RFC 363", + series="Internet Request for Comments", + type="RFC", + number="363", + pages="1--13", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 402", +url="https://www.rfc-editor.org/rfc/rfc363.txt", + key="RFC 363", + doi="10.17487/RFC0363", + } + +@misc{rfc364, + author="M.D. Abrams", + title="{Serving remote users on the ARPANET}", + howpublished="RFC 364", + series="Internet Request for Comments", + type="RFC", + number="364", + pages="1--6", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc364.txt", + key="RFC 364", + doi="10.17487/RFC0364", + } + +@misc{rfc365, + author="D.C. Walden", + title="{Letter to All TIP Users}", + howpublished="RFC 365", + series="Internet Request for Comments", + type="RFC", + number="365", + pages="1--5", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc365.txt", + key="RFC 365", + doi="10.17487/RFC0365", + } + +@misc{rfc366, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 366", + series="Internet Request for Comments", + type="RFC", + number="366", + pages="1--4", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 367", +url="https://www.rfc-editor.org/rfc/rfc366.txt", + key="RFC 366", + doi="10.17487/RFC0366", + } + +@misc{rfc367, + author="E. Westheimer", + title="{Network host status}", + howpublished="RFC 367", + series="Internet Request for Comments", + type="RFC", + number="367", + pages="1--4", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 370", +url="https://www.rfc-editor.org/rfc/rfc367.txt", + key="RFC 367", + doi="10.17487/RFC0367", + } + +@misc{rfc368, + author="R.T. Braden", + title="{Comments on ``Proposed Remote Job Entry Protocol''}", + howpublished="RFC 368", + series="Internet Request for Comments", + type="RFC", + number="368", + pages="1--2", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc368.txt", + key="RFC 368", + doi="10.17487/RFC0368", + } + +@misc{rfc369, + author="J.R. Pickens", + title="{Evaluation of ARPANET services January-March, 1972}", + howpublished="RFC 369", + series="Internet Request for Comments", + type="RFC", + number="369", + pages="1--11", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc369.txt", + key="RFC 369", + doi="10.17487/RFC0369", + } + +@misc{rfc370, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 370", + series="Internet Request for Comments", + type="RFC", + number="370", + pages="1--5", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 376", +url="https://www.rfc-editor.org/rfc/rfc370.txt", + key="RFC 370", + doi="10.17487/RFC0370", + } + +@misc{rfc371, + author="R.E. Kahn", + title="{Demonstration at International Computer Communications Conference}", + howpublished="RFC 371", + series="Internet Request for Comments", + type="RFC", + number="371", + pages="1--2", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc371.txt", + key="RFC 371", + doi="10.17487/RFC0371", + } + +@misc{rfc372, + author="R.W. Watson", + title="{Notes on a Conversation with Bob Kahn on the ICCC}", + howpublished="RFC 372", + series="Internet Request for Comments", + type="RFC", + number="372", + pages="1--4", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc372.txt", + key="RFC 372", + doi="10.17487/RFC0372", + } + +@misc{rfc373, + author="J. McCarthy", + title="{Arbitrary Character Sets}", + howpublished="RFC 373", + series="Internet Request for Comments", + type="RFC", + number="373", + pages="1--4", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc373.txt", + key="RFC 373", + doi="10.17487/RFC0373", + } + +@misc{rfc374, + author="A.M. McKenzie", + title="{IMP System Announcement}", + howpublished="RFC 374", + series="Internet Request for Comments", + type="RFC", + number="374", + pages="1--2", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc374.txt", + key="RFC 374", + doi="10.17487/RFC0374", + } + +@misc{rfc376, + author="E. Westheimer", + title="{Network Host Status}", + howpublished="RFC 376", + series="Internet Request for Comments", + type="RFC", + number="376", + pages="1--5", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc376.txt", + key="RFC 376", + doi="10.17487/RFC0376", + } + +@misc{rfc377, + author="R.T. Braden", + title="{Using TSO via ARPA Network Virtual Terminal}", + howpublished="RFC 377", + series="Internet Request for Comments", + type="RFC", + number="377", + pages="1--4", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc377.txt", + key="RFC 377", + doi="10.17487/RFC0377", + } + +@misc{rfc378, + author="A.M. McKenzie", + title="{Traffic statistics (July 1972)}", + howpublished="RFC 378", + series="Internet Request for Comments", + type="RFC", + number="378", + pages="1--3", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 391", +url="https://www.rfc-editor.org/rfc/rfc378.txt", + key="RFC 378", + doi="10.17487/RFC0378", + } + +@misc{rfc379, + author="R. Braden", + title="{Using TSO at CCN}", + howpublished="RFC 379", + series="Internet Request for Comments", + type="RFC", + number="379", + pages="1--5", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc379.txt", + key="RFC 379", + doi="10.17487/RFC0379", + } + +@misc{rfc381, + author="J.M. McQuillan", + title="{Three aids to improved network operation}", + howpublished="RFC 381", + series="Internet Request for Comments", + type="RFC", + number="381", + pages="1--4", + year=1972, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 394", +url="https://www.rfc-editor.org/rfc/rfc381.txt", + key="RFC 381", + doi="10.17487/RFC0381", + } + +@misc{rfc382, + author="L. McDaniel", + title="{Mathematical Software on the ARPA Network}", + howpublished="RFC 382", + series="Internet Request for Comments", + type="RFC", + number="382", + pages="1--1", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc382.txt", + key="RFC 382", + doi="10.17487/RFC0382", + } + +@misc{rfc384, + author="J.B. North", + title="{Official site idents for organizations in the ARPA Network}", + howpublished="RFC 384", + series="Internet Request for Comments", + type="RFC", + number="384", + pages="1--4", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc384.txt", + key="RFC 384", + doi="10.17487/RFC0384", + } + +@misc{rfc385, + author="A.K. Bhushan", + title="{Comments on the File Transfer Protocol}", + howpublished="RFC 385", + series="Internet Request for Comments", + type="RFC", + number="385", + pages="1--6", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 414", +url="https://www.rfc-editor.org/rfc/rfc385.txt", + key="RFC 385", + keywords="FTP", + doi="10.17487/RFC0385", + } + +@misc{rfc386, + author="B. Cosell and D.C. Walden", + title="{Letter to TIP users-2}", + howpublished="RFC 386", + series="Internet Request for Comments", + type="RFC", + number="386", + pages="1--5", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc386.txt", + key="RFC 386", + doi="10.17487/RFC0386", + } + +@misc{rfc387, + author="K.C. Kelley and J. Meir", + title="{Some experiences in implementing Network Graphics Protocol Level 0}", + howpublished="RFC 387", + series="Internet Request for Comments", + type="RFC", + number="387", + pages="1--5", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 401", +url="https://www.rfc-editor.org/rfc/rfc387.txt", + key="RFC 387", + doi="10.17487/RFC0387", + } + +@misc{rfc388, + author="V. Cerf", + title="{NCP statistics}", + howpublished="RFC 388", + series="Internet Request for Comments", + type="RFC", + number="388", + pages="1--5", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc388.txt", + key="RFC 388", + doi="10.17487/RFC0388", + } + +@misc{rfc389, + author="B. Noble", + title="{UCLA Campus Computing Network Liaison Staff for ARPA Network}", + howpublished="RFC 389", + series="Internet Request for Comments", + type="RFC", + number="389", + pages="1--2", + year=1972, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 423", +url="https://www.rfc-editor.org/rfc/rfc389.txt", + key="RFC 389", + doi="10.17487/RFC0389", + } + +@misc{rfc390, + author="R.T. Braden", + title="{TSO Scenario}", + howpublished="RFC 390", + series="Internet Request for Comments", + type="RFC", + number="390", + pages="1--4", + year=1972, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc390.txt", + key="RFC 390", + doi="10.17487/RFC0390", + } + +@misc{rfc391, + author="A.M. McKenzie", + title="{Traffic statistics (August 1972)}", + howpublished="RFC 391", + series="Internet Request for Comments", + type="RFC", + number="391", + pages="1--3", + year=1972, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc391.txt", + key="RFC 391", + doi="10.17487/RFC0391", + } + +@misc{rfc392, + author="G. Hicks and B.D. Wessler", + title="{Measurement of host costs for transmitting network data}", + howpublished="RFC 392", + series="Internet Request for Comments", + type="RFC", + number="392", + pages="1--6", + year=1972, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc392.txt", + key="RFC 392", + doi="10.17487/RFC0392", + } + +@misc{rfc393, + author="J.M. Winett", + title="{Comments on Telnet Protocol Changes}", + howpublished="RFC 393", + series="Internet Request for Comments", + type="RFC", + number="393", + pages="1--4", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc393.txt", + key="RFC 393", + doi="10.17487/RFC0393", + } + +@misc{rfc394, + author="J.M. McQuillan", + title="{Two Proposed Changes to the IMP-Host Protocol}", + howpublished="RFC 394", + series="Internet Request for Comments", + type="RFC", + number="394", + pages="1--3", + year=1972, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc394.txt", + key="RFC 394", + doi="10.17487/RFC0394", + } + +@misc{rfc395, + author="J.M. McQuillan", + title="{Switch Settings on IMPs and TIPs}", + howpublished="RFC 395", + series="Internet Request for Comments", + type="RFC", + number="395", + pages="1--1", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc395.txt", + key="RFC 395", + doi="10.17487/RFC0395", + } + +@misc{rfc396, + author="S. Bunch", + title="{Network Graphics Working Group Meeting - Second Iteration}", + howpublished="RFC 396", + series="Internet Request for Comments", + type="RFC", + number="396", + pages="1--1", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 474", +url="https://www.rfc-editor.org/rfc/rfc396.txt", + key="RFC 396", + doi="10.17487/RFC0396", + } + +@misc{rfc398, + author="J.R. Pickens and E. Faeh", + title="{UCSB Online Graphics}", + howpublished="RFC 398", + series="Internet Request for Comments", + type="RFC", + number="398", + pages="1--2", + year=1972, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc398.txt", + key="RFC 398", + doi="10.17487/RFC0398", + } + +@misc{rfc399, + author="M. Krilanovich", + title="{SMFS Login and Logout}", + howpublished="RFC 399", + series="Internet Request for Comments", + type="RFC", + number="399", + pages="1--2", + year=1972, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 431", +url="https://www.rfc-editor.org/rfc/rfc399.txt", + key="RFC 399", + doi="10.17487/RFC0399", + } + +@misc{rfc400, + author="A.M. McKenzie", + title="{Traffic Statistics (September 1972)}", + howpublished="RFC 400", + series="Internet Request for Comments", + type="RFC", + number="400", + pages="1--3", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc400.txt", + key="RFC 400", + doi="10.17487/RFC0400", + } + +@misc{rfc401, + author="J. Hansen", + title="{Conversion of NGP-0 Coordinates to Device Specific Coordinates}", + howpublished="RFC 401", + series="Internet Request for Comments", + type="RFC", + number="401", + pages="1--2", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc401.txt", + key="RFC 401", + doi="10.17487/RFC0401", + } + +@misc{rfc402, + author="J.B. North", + title="{ARPA Network Mailing Lists}", + howpublished="RFC 402", + series="Internet Request for Comments", + type="RFC", + number="402", + pages="1--16", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc402.txt", + key="RFC 402", + doi="10.17487/RFC0402", + } + +@misc{rfc403, + author="G. Hicks", + title="{Desirability of a Network 1108 Service}", + howpublished="RFC 403", + series="Internet Request for Comments", + type="RFC", + number="403", + pages="1--5", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc403.txt", + key="RFC 403", + doi="10.17487/RFC0403", + } + +@misc{rfc404, + author="A.M. McKenzie", + title="{Host Address Changes Involving Rand and ISI}", + howpublished="RFC 404", + series="Internet Request for Comments", + type="RFC", + number="404", + pages="1--1", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 405", +url="https://www.rfc-editor.org/rfc/rfc404.txt", + key="RFC 404", + doi="10.17487/RFC0404", + } + +@misc{rfc405, + author="A.M. McKenzie", + title="{Correction to RFC 404}", + howpublished="RFC 405", + series="Internet Request for Comments", + type="RFC", + number="405", + pages="1--1", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc405.txt", + key="RFC 405", + doi="10.17487/RFC0405", + } + +@misc{rfc406, + author="J.M. McQuillan", + title="{Scheduled IMP Software Releases}", + howpublished="RFC 406", + series="Internet Request for Comments", + type="RFC", + number="406", + pages="1--2", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc406.txt", + key="RFC 406", + doi="10.17487/RFC0406", + } + +@misc{rfc407, + author="R.D. Bressler and R. Guida and A.M. McKenzie", + title="{Remote Job Entry Protocol}", + howpublished="RFC 407 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="407", + pages="1--21", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc407.txt", + key="RFC 407", + keywords="RJE", + doi="10.17487/RFC0407", + } + +@misc{rfc408, + author="A.D. Owen and J. Postel", + title="{NETBANK}", + howpublished="RFC 408", + series="Internet Request for Comments", + type="RFC", + number="408", + pages="1--1", + year=1972, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc408.txt", + key="RFC 408", + doi="10.17487/RFC0408", + } + +@misc{rfc409, + author="J.E. White", + title="{Tenex interface to UCSB's Simple-Minded File System}", + howpublished="RFC 409", + series="Internet Request for Comments", + type="RFC", + number="409", + pages="1--8", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc409.txt", + key="RFC 409", + doi="10.17487/RFC0409", + } + +@misc{rfc410, + author="J.M. McQuillan", + title="{Removal of the 30-Second Delay When Hosts Come Up}", + howpublished="RFC 410", + series="Internet Request for Comments", + type="RFC", + number="410", + pages="1--2", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc410.txt", + key="RFC 410", + doi="10.17487/RFC0410", + } + +@misc{rfc411, + author="M.A. Padlipsky", + title="{New MULTICS Network Software Features}", + howpublished="RFC 411", + series="Internet Request for Comments", + type="RFC", + number="411", + pages="1--2", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc411.txt", + key="RFC 411", + doi="10.17487/RFC0411", + } + +@misc{rfc412, + author="G. Hicks", + title="{User FTP Documentation}", + howpublished="RFC 412", + series="Internet Request for Comments", + type="RFC", + number="412", + pages="1--10", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc412.txt", + key="RFC 412", + doi="10.17487/RFC0412", + } + +@misc{rfc413, + author="A.M. McKenzie", + title="{Traffic statistics (October 1972)}", + howpublished="RFC 413", + series="Internet Request for Comments", + type="RFC", + number="413", + pages="1--10", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc413.txt", + key="RFC 413", + doi="10.17487/RFC0413", + } + +@misc{rfc414, + author="A.K. Bhushan", + title="{File Transfer Protocol (FTP) status and further comments}", + howpublished="RFC 414", + series="Internet Request for Comments", + type="RFC", + number="414", + pages="1--5", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc414.txt", + key="RFC 414", + doi="10.17487/RFC0414", + } + +@misc{rfc415, + author="H. Murray", + title="{Tenex bandwidth}", + howpublished="RFC 415", + series="Internet Request for Comments", + type="RFC", + number="415", + pages="1--2", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc415.txt", + key="RFC 415", + doi="10.17487/RFC0415", + } + +@misc{rfc416, + author="J.C. Norton", + title="{ARC System Will Be Unavailable for Use During Thanksgiving Week}", + howpublished="RFC 416", + series="Internet Request for Comments", + type="RFC", + number="416", + pages="1--2", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc416.txt", + key="RFC 416", + doi="10.17487/RFC0416", + } + +@misc{rfc417, + author="J. Postel and C. Kline", + title="{Link usage violation}", + howpublished="RFC 417", + series="Internet Request for Comments", + type="RFC", + number="417", + pages="1--1", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc417.txt", + key="RFC 417", + doi="10.17487/RFC0417", + } + +@misc{rfc418, + author="W. Hathaway", + title="{Server File Transfer Under TSS/360 At NASA-Ames Research Center}", + howpublished="RFC 418", + series="Internet Request for Comments", + type="RFC", + number="418", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc418.txt", + key="RFC 418", + doi="10.17487/RFC0418", + } + +@misc{rfc419, + author="A. Vezza", + title="{To: Network liaisons and station agents}", + howpublished="RFC 419", + series="Internet Request for Comments", + type="RFC", + number="419", + pages="1--1", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc419.txt", + key="RFC 419", + doi="10.17487/RFC0419", + } + +@misc{rfc420, + author="H. Murray", + title="{CCA ICCC weather demo}", + howpublished="RFC 420", + series="Internet Request for Comments", + type="RFC", + number="420", + pages="1--8", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc420.txt", + key="RFC 420", + doi="10.17487/RFC0420", + } + +@misc{rfc421, + author="A.M. McKenzie", + title="{Software Consulting Service for Network Users}", + howpublished="RFC 421", + series="Internet Request for Comments", + type="RFC", + number="421", + pages="1--2", + year=1972, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc421.txt", + key="RFC 421", + doi="10.17487/RFC0421", + } + +@misc{rfc422, + author="A.M. McKenzie", + title="{Traffic statistics (November 1972)}", + howpublished="RFC 422", + series="Internet Request for Comments", + type="RFC", + number="422", + pages="1--4", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc422.txt", + key="RFC 422", + doi="10.17487/RFC0422", + } + +@misc{rfc423, + author="B. Noble", + title="{UCLA Campus Computing Network Liaison Staff for ARPANET}", + howpublished="RFC 423", + series="Internet Request for Comments", + type="RFC", + number="423", + pages="1--2", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc423.txt", + key="RFC 423", + doi="10.17487/RFC0423", + } + +@misc{rfc425, + author="R.D. Bressler", + title="{``But my NCP costs \$500 a day''}", + howpublished="RFC 425", + series="Internet Request for Comments", + type="RFC", + number="425", + pages="1--1", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc425.txt", + key="RFC 425", + doi="10.17487/RFC0425", + } + +@misc{rfc426, + author="R. Thomas", + title="{Reconnection Protocol}", + howpublished="RFC 426", + series="Internet Request for Comments", + type="RFC", + number="426", + pages="1--12", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc426.txt", + key="RFC 426", + doi="10.17487/RFC0426", + } + +@misc{rfc429, + author="J. Postel", + title="{Character Generator Process}", + howpublished="RFC 429", + series="Internet Request for Comments", + type="RFC", + number="429", + pages="1--1", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc429.txt", + key="RFC 429", + doi="10.17487/RFC0429", + } + +@misc{rfc430, + author="R.T. Braden", + title="{Comments on File Transfer Protocol}", + howpublished="RFC 430", + series="Internet Request for Comments", + type="RFC", + number="430", + pages="1--8", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc430.txt", + key="RFC 430", + doi="10.17487/RFC0430", + } + +@misc{rfc431, + author="M. Krilanovich", + title="{Update on SMFS Login and Logout}", + howpublished="RFC 431", + series="Internet Request for Comments", + type="RFC", + number="431", + pages="1--3", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc431.txt", + key="RFC 431", + doi="10.17487/RFC0431", + } + +@misc{rfc432, + author="N. Neigus", + title="{Network logical map}", + howpublished="RFC 432", + series="Internet Request for Comments", + type="RFC", + number="432", + pages="1--1", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc432.txt", + key="RFC 432", + doi="10.17487/RFC0432", + } + +@misc{rfc433, + author="J. Postel", + title="{Socket number list}", + howpublished="RFC 433", + series="Internet Request for Comments", + type="RFC", + number="433", + pages="1--5", + year=1972, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 503", +url="https://www.rfc-editor.org/rfc/rfc433.txt", + key="RFC 433", + doi="10.17487/RFC0433", + } + +@misc{rfc434, + author="A.M. McKenzie", + title="{IMP/TIP memory retrofit schedule}", + howpublished="RFC 434", + series="Internet Request for Comments", + type="RFC", + number="434", + pages="1--2", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 447", +url="https://www.rfc-editor.org/rfc/rfc434.txt", + key="RFC 434", + doi="10.17487/RFC0434", + } + +@misc{rfc435, + author="B. Cosell and D.C. Walden", + title="{Telnet issues}", + howpublished="RFC 435", + series="Internet Request for Comments", + type="RFC", + number="435", + pages="1--10", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc435.txt", + key="RFC 435", + doi="10.17487/RFC0435", + } + +@misc{rfc436, + author="M. Krilanovich", + title="{Announcement of RJS at UCSB}", + howpublished="RFC 436", + series="Internet Request for Comments", + type="RFC", + number="436", + pages="1--1", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc436.txt", + key="RFC 436", + doi="10.17487/RFC0436", + } + +@misc{rfc437, + author="E. Faeh", + title="{Data Reconfiguration Service at UCSB}", + howpublished="RFC 437", + series="Internet Request for Comments", + type="RFC", + number="437", + pages="1--10", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc437.txt", + key="RFC 437", + doi="10.17487/RFC0437", + } + +@misc{rfc438, + author="R. Thomas and R. Clements", + title="{FTP server-server interaction}", + howpublished="RFC 438", + series="Internet Request for Comments", + type="RFC", + number="438", + pages="1--3", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc438.txt", + key="RFC 438", + doi="10.17487/RFC0438", + } + +@misc{rfc439, + author="V. Cerf", + title="{PARRY encounters the DOCTOR}", + howpublished="RFC 439", + series="Internet Request for Comments", + type="RFC", + number="439", + pages="1--7", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc439.txt", + key="RFC 439", + doi="10.17487/RFC0439", + } + +@misc{rfc440, + author="D.C. Walden", + title="{Scheduled network software maintenance}", + howpublished="RFC 440", + series="Internet Request for Comments", + type="RFC", + number="440", + pages="1--1", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc440.txt", + key="RFC 440", + doi="10.17487/RFC0440", + } + +@misc{rfc441, + author="R.D. Bressler and R. Thomas", + title="{Inter-Entity Communication - an experiment}", + howpublished="RFC 441", + series="Internet Request for Comments", + type="RFC", + number="441", + pages="1--7", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc441.txt", + key="RFC 441", + doi="10.17487/RFC0441", + } + +@misc{rfc442, + author="V. Cerf", + title="{Current flow-control scheme for IMPSYS}", + howpublished="RFC 442", + series="Internet Request for Comments", + type="RFC", + number="442", + pages="1--7", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 449", +url="https://www.rfc-editor.org/rfc/rfc442.txt", + key="RFC 442", + doi="10.17487/RFC0442", + } + +@misc{rfc443, + author="A.M. McKenzie", + title="{Traffic statistics (December 1972)}", + howpublished="RFC 443", + series="Internet Request for Comments", + type="RFC", + number="443", + pages="1--3", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc443.txt", + key="RFC 443", + doi="10.17487/RFC0443", + } + +@misc{rfc445, + author="A.M. McKenzie", + title="{IMP/TIP preventive maintenance schedule}", + howpublished="RFC 445", + series="Internet Request for Comments", + type="RFC", + number="445", + pages="1--2", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc445.txt", + key="RFC 445", + doi="10.17487/RFC0445", + } + +@misc{rfc446, + author="L.P. Deutsch", + title="{Proposal to consider a network program resource notebook}", + howpublished="RFC 446", + series="Internet Request for Comments", + type="RFC", + number="446", + pages="1--2", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc446.txt", + key="RFC 446", + doi="10.17487/RFC0446", + } + +@misc{rfc447, + author="A.M. McKenzie", + title="{IMP/TIP memory retrofit schedule}", + howpublished="RFC 447", + series="Internet Request for Comments", + type="RFC", + number="447", + pages="1--2", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 476", +url="https://www.rfc-editor.org/rfc/rfc447.txt", + key="RFC 447", + doi="10.17487/RFC0447", + } + +@misc{rfc448, + author="R.T. Braden", + title="{Print files in FTP}", + howpublished="RFC 448", + series="Internet Request for Comments", + type="RFC", + number="448", + pages="1--3", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc448.txt", + key="RFC 448", + doi="10.17487/RFC0448", + } + +@misc{rfc449, + author="D.C. Walden", + title="{Current flow-control scheme for IMPSYS}", + howpublished="RFC 449", + series="Internet Request for Comments", + type="RFC", + number="449", + pages="1--1", + year=1973, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc449.txt", + key="RFC 449", + doi="10.17487/RFC0449", + } + +@misc{rfc450, + author="M.A. Padlipsky", + title="{MULTICS sampling timeout change}", + howpublished="RFC 450", + series="Internet Request for Comments", + type="RFC", + number="450", + pages="1--1", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc450.txt", + key="RFC 450", + doi="10.17487/RFC0450", + } + +@misc{rfc451, + author="M.A. Padlipsky", + title="{Tentative proposal for a Unified User Level Protocol}", + howpublished="RFC 451", + series="Internet Request for Comments", + type="RFC", + number="451", + pages="1--3", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc451.txt", + key="RFC 451", + doi="10.17487/RFC0451", + } + +@misc{rfc452, + author="J. Winett", + title="{TELNET Command at Host LL}", + howpublished="RFC 452", + series="Internet Request for Comments", + type="RFC", + number="452", + pages="1--14", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc452.txt", + key="RFC 452", + doi="10.17487/RFC0452", + } + +@misc{rfc453, + author="M.D. Kudlick", + title="{Meeting announcement to discuss a network mail system}", + howpublished="RFC 453", + series="Internet Request for Comments", + type="RFC", + number="453", + pages="1--3", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc453.txt", + key="RFC 453", + doi="10.17487/RFC0453", + } + +@misc{rfc454, + author="A.M. McKenzie", + title="{File Transfer Protocol - meeting announcement and a new proposed document}", + howpublished="RFC 454", + series="Internet Request for Comments", + type="RFC", + number="454", + pages="1--35", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc454.txt", + key="RFC 454", + keywords="FTP", + doi="10.17487/RFC0454", + } + +@misc{rfc455, + author="A.M. McKenzie", + title="{Traffic statistics (January 1973)}", + howpublished="RFC 455", + series="Internet Request for Comments", + type="RFC", + number="455", + pages="1--3", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc455.txt", + key="RFC 455", + doi="10.17487/RFC0455", + } + +@misc{rfc456, + author="M.D. Kudlick", + title="{Memorandum: Date change of mail meeting}", + howpublished="RFC 456", + series="Internet Request for Comments", + type="RFC", + number="456", + pages="1--1", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc456.txt", + key="RFC 456", + doi="10.17487/RFC0456", + } + +@misc{rfc457, + author="D.C. Walden", + title="{TIPUG}", + howpublished="RFC 457", + series="Internet Request for Comments", + type="RFC", + number="457", + pages="1--1", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc457.txt", + key="RFC 457", + doi="10.17487/RFC0457", + } + +@misc{rfc458, + author="R.D. Bressler and R. Thomas", + title="{Mail retrieval via FTP}", + howpublished="RFC 458", + series="Internet Request for Comments", + type="RFC", + number="458", + pages="1--2", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc458.txt", + key="RFC 458", + doi="10.17487/RFC0458", + } + +@misc{rfc459, + author="W. Kantrowitz", + title="{Network questionnaires}", + howpublished="RFC 459", + series="Internet Request for Comments", + type="RFC", + number="459", + pages="1--1", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc459.txt", + key="RFC 459", + doi="10.17487/RFC0459", + } + +@misc{rfc460, + author="C. Kline", + title="{NCP survey}", + howpublished="RFC 460", + series="Internet Request for Comments", + type="RFC", + number="460", + pages="1--7", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc460.txt", + key="RFC 460", + doi="10.17487/RFC0460", + } + +@misc{rfc461, + author="A.M. McKenzie", + title="{Telnet Protocol meeting announcement}", + howpublished="RFC 461", + series="Internet Request for Comments", + type="RFC", + number="461", + pages="1--1", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc461.txt", + key="RFC 461", + doi="10.17487/RFC0461", + } + +@misc{rfc462, + author="J. Iseli and D. Crocker", + title="{Responding to user needs}", + howpublished="RFC 462", + series="Internet Request for Comments", + type="RFC", + number="462", + pages="1--2", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc462.txt", + key="RFC 462", + doi="10.17487/RFC0462", + } + +@misc{rfc463, + author="A.K. Bhushan", + title="{FTP comments and response to RFC 430}", + howpublished="RFC 463", + series="Internet Request for Comments", + type="RFC", + number="463", + pages="1--3", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc463.txt", + key="RFC 463", + doi="10.17487/RFC0463", + } + +@misc{rfc464, + author="M.D. Kudlick", + title="{Resource notebook framework}", + howpublished="RFC 464", + series="Internet Request for Comments", + type="RFC", + number="464", + pages="1--2", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc464.txt", + key="RFC 464", + doi="10.17487/RFC0464", + } + +@misc{rfc466, + author="J.M. Winett", + title="{Telnet logger/server for host LL-67}", + howpublished="RFC 466", + series="Internet Request for Comments", + type="RFC", + number="466", + pages="1--9", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc466.txt", + key="RFC 466", + doi="10.17487/RFC0466", + } + +@misc{rfc467, + author="J.D. Burchfiel and R.S. Tomlinson", + title="{Proposed change to Host-Host Protocol: Resynchronization of connection status}", + howpublished="RFC 467", + series="Internet Request for Comments", + type="RFC", + number="467", + pages="1--7", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 492", +url="https://www.rfc-editor.org/rfc/rfc467.txt", + key="RFC 467", + doi="10.17487/RFC0467", + } + +@misc{rfc468, + author="R.T. Braden", + title="{FTP data compression}", + howpublished="RFC 468", + series="Internet Request for Comments", + type="RFC", + number="468", + pages="1--7", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc468.txt", + key="RFC 468", + doi="10.17487/RFC0468", + } + +@misc{rfc469, + author="M.D. Kudlick", + title="{Network mail meeting summary}", + howpublished="RFC 469", + series="Internet Request for Comments", + type="RFC", + number="469", + pages="1--10", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc469.txt", + key="RFC 469", + keywords="network, mail, meeting", + doi="10.17487/RFC0469", + } + +@misc{rfc470, + author="R. Thomas", + title="{Change in socket for TIP news facility}", + howpublished="RFC 470", + series="Internet Request for Comments", + type="RFC", + number="470", + pages="1--1", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc470.txt", + key="RFC 470", + doi="10.17487/RFC0470", + } + +@misc{rfc471, + author="R. Thomas", + title="{Workshop on multi-site executive programs}", + howpublished="RFC 471", + series="Internet Request for Comments", + type="RFC", + number="471", + pages="1--2", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc471.txt", + key="RFC 471", + doi="10.17487/RFC0471", + } + +@misc{rfc472, + author="S. Bunch", + title="{Illinois' reply to Maxwell's request for graphics information (NIC 14925)}", + howpublished="RFC 472", + series="Internet Request for Comments", + type="RFC", + number="472", + pages="1--2", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc472.txt", + key="RFC 472", + doi="10.17487/RFC0472", + } + +@misc{rfc473, + author="D.C. Walden", + title="{MIX and MIXAL?}", + howpublished="RFC 473", + series="Internet Request for Comments", + type="RFC", + number="473", + pages="1--1", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc473.txt", + key="RFC 473", + doi="10.17487/RFC0473", + } + +@misc{rfc474, + author="S. Bunch", + title="{Announcement of NGWG meeting: Call for papers}", + howpublished="RFC 474", + series="Internet Request for Comments", + type="RFC", + number="474", + pages="1--2", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc474.txt", + key="RFC 474", + doi="10.17487/RFC0474", + } + +@misc{rfc475, + author="A.K. Bhushan", + title="{FTP and Network Mail System}", + howpublished="RFC 475", + series="Internet Request for Comments", + type="RFC", + number="475", + pages="1--5", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc475.txt", + key="RFC 475", + doi="10.17487/RFC0475", + } + +@misc{rfc476, + author="A.M. McKenzie", + title="{IMP/TIP memory retrofit schedule (rev 2)}", + howpublished="RFC 476", + series="Internet Request for Comments", + type="RFC", + number="476", + pages="1--2", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc476.txt", + key="RFC 476", + doi="10.17487/RFC0476", + } + +@misc{rfc477, + author="M. Krilanovich", + title="{Remote Job Service at UCSB}", + howpublished="RFC 477", + series="Internet Request for Comments", + type="RFC", + number="477", + pages="1--19", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc477.txt", + key="RFC 477", + doi="10.17487/RFC0477", + } + +@misc{rfc478, + author="R.D. Bressler and R. Thomas", + title="{FTP server-server interaction - II}", + howpublished="RFC 478", + series="Internet Request for Comments", + type="RFC", + number="478", + pages="1--2", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc478.txt", + key="RFC 478", + doi="10.17487/RFC0478", + } + +@misc{rfc479, + author="J.E. White", + title="{Use of FTP by the NIC Journal}", + howpublished="RFC 479", + series="Internet Request for Comments", + type="RFC", + number="479", + pages="1--5", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc479.txt", + key="RFC 479", + doi="10.17487/RFC0479", + } + +@misc{rfc480, + author="J.E. White", + title="{Host-dependent FTP parameters}", + howpublished="RFC 480", + series="Internet Request for Comments", + type="RFC", + number="480", + pages="1--1", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc480.txt", + key="RFC 480", + doi="10.17487/RFC0480", + } + +@misc{rfc482, + author="A.M. McKenzie", + title="{Traffic statistics (February 1973)}", + howpublished="RFC 482", + series="Internet Request for Comments", + type="RFC", + number="482", + pages="1--4", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 497", +url="https://www.rfc-editor.org/rfc/rfc482.txt", + key="RFC 482", + doi="10.17487/RFC0482", + } + +@misc{rfc483, + author="M.D. Kudlick", + title="{Cancellation of the resource notebook framework meeting}", + howpublished="RFC 483", + series="Internet Request for Comments", + type="RFC", + number="483", + pages="1--1", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc483.txt", + key="RFC 483", + doi="10.17487/RFC0483", + } + +@misc{rfc485, + author="J.R. Pickens", + title="{MIX and MIXAL at UCSB}", + howpublished="RFC 485", + series="Internet Request for Comments", + type="RFC", + number="485", + pages="1--1", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc485.txt", + key="RFC 485", + doi="10.17487/RFC0485", + } + +@misc{rfc486, + author="R.D. Bressler", + title="{Data transfer revisited}", + howpublished="RFC 486", + series="Internet Request for Comments", + type="RFC", + number="486", + pages="1--2", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc486.txt", + key="RFC 486", + keywords="RJE, FTP", + doi="10.17487/RFC0486", + } + +@misc{rfc487, + author="R.D. Bressler", + title="{Free file transfer}", + howpublished="RFC 487", + series="Internet Request for Comments", + type="RFC", + number="487", + pages="1--2", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc487.txt", + key="RFC 487", + keywords="FTP", + doi="10.17487/RFC0487", + } + +@misc{rfc488, + author="M.F. Auerbach", + title="{NLS classes at network sites}", + howpublished="RFC 488", + series="Internet Request for Comments", + type="RFC", + number="488", + pages="1--2", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc488.txt", + key="RFC 488", + doi="10.17487/RFC0488", + } + +@misc{rfc489, + author="J. Postel", + title="{Comment on resynchronization of connection status proposal}", + howpublished="RFC 489", + series="Internet Request for Comments", + type="RFC", + number="489", + pages="1--1", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc489.txt", + key="RFC 489", + doi="10.17487/RFC0489", + } + +@misc{rfc490, + author="J.R. Pickens", + title="{Surrogate RJS for UCLA-CCN}", + howpublished="RFC 490", + series="Internet Request for Comments", + type="RFC", + number="490", + pages="1--6", + year=1973, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc490.txt", + key="RFC 490", + doi="10.17487/RFC0490", + } + +@misc{rfc491, + author="M.A. Padlipsky", + title="{What is ``Free''?}", + howpublished="RFC 491", + series="Internet Request for Comments", + type="RFC", + number="491", + pages="1--2", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc491.txt", + key="RFC 491", + doi="10.17487/RFC0491", + } + +@misc{rfc492, + author="E. Meyer", + title="{Response to RFC 467}", + howpublished="RFC 492", + series="Internet Request for Comments", + type="RFC", + number="492", + pages="1--7", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc492.txt", + key="RFC 492", + doi="10.17487/RFC0492", + } + +@misc{rfc493, + author="J.C. Michener and I.W. Cotton and K.C. Kelley and D.E. Liddle and E. Meyer", + title="{GRAPHICS PROTOCOL}", + howpublished="RFC 493", + series="Internet Request for Comments", + type="RFC", + number="493", + pages="1--28", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc493.txt", + key="RFC 493", + doi="10.17487/RFC0493", + } + +@misc{rfc494, + author="D.C. Walden", + title="{Availability of MIX and MIXAL in the Network}", + howpublished="RFC 494", + series="Internet Request for Comments", + type="RFC", + number="494", + pages="1--1", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc494.txt", + key="RFC 494", + doi="10.17487/RFC0494", + } + +@misc{rfc495, + author="A.M. McKenzie", + title="{Telnet Protocol specifications}", + howpublished="RFC 495", + series="Internet Request for Comments", + type="RFC", + number="495", + pages="1--2", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 562", +url="https://www.rfc-editor.org/rfc/rfc495.txt", + key="RFC 495", + doi="10.17487/RFC0495", + } + +@misc{rfc496, + author="M.F. Auerbach", + title="{TNLS quick reference card is available}", + howpublished="RFC 496", + series="Internet Request for Comments", + type="RFC", + number="496", + pages="1--1", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc496.txt", + key="RFC 496", + doi="10.17487/RFC0496", + } + +@misc{rfc497, + author="A.M. McKenzie", + title="{Traffic Statistics (March 1973)}", + howpublished="RFC 497", + series="Internet Request for Comments", + type="RFC", + number="497", + pages="1--4", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc497.txt", + key="RFC 497", + doi="10.17487/RFC0497", + } + +@misc{rfc498, + author="R.T. Braden", + title="{On mail service to CCN}", + howpublished="RFC 498", + series="Internet Request for Comments", + type="RFC", + number="498", + pages="1--3", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc498.txt", + key="RFC 498", + doi="10.17487/RFC0498", + } + +@misc{rfc499, + author="B.R. Reussow", + title="{Harvard's network RJE}", + howpublished="RFC 499", + series="Internet Request for Comments", + type="RFC", + number="499", + pages="1--6", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc499.txt", + key="RFC 499", + doi="10.17487/RFC0499", + } + +@misc{rfc500, + author="A. Shoshani and I. Spiegler", + title="{Integration of data management systems on a computer network}", + howpublished="RFC 500", + series="Internet Request for Comments", + type="RFC", + number="500", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc500.txt", + key="RFC 500", + doi="10.17487/RFC0500", + } + +@misc{rfc501, + author="K.T. Pogran", + title="{Un-muddling ``free file transfer''}", + howpublished="RFC 501", + series="Internet Request for Comments", + type="RFC", + number="501", + pages="1--5", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc501.txt", + key="RFC 501", + keywords="FTP", + doi="10.17487/RFC0501", + } + +@misc{rfc503, + author="N. Neigus and J. Postel", + title="{Socket number list}", + howpublished="RFC 503", + series="Internet Request for Comments", + type="RFC", + number="503", + pages="1--8", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 739", +url="https://www.rfc-editor.org/rfc/rfc503.txt", + key="RFC 503", + doi="10.17487/RFC0503", + } + +@misc{rfc504, + author="R. Thomas", + title="{Distributed resources workshop announcement}", + howpublished="RFC 504", + series="Internet Request for Comments", + type="RFC", + number="504", + pages="1--5", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc504.txt", + key="RFC 504", + doi="10.17487/RFC0504", + } + +@misc{rfc505, + author="M.A. Padlipsky", + title="{Two solutions to a file transfer access problem}", + howpublished="RFC 505", + series="Internet Request for Comments", + type="RFC", + number="505", + pages="1--3", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc505.txt", + key="RFC 505", + keywords="FTP, free", + doi="10.17487/RFC0505", + } + +@misc{rfc506, + author="M.A. Padlipsky", + title="{FTP command naming problem}", + howpublished="RFC 506", + series="Internet Request for Comments", + type="RFC", + number="506", + pages="1--1", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc506.txt", + key="RFC 506", + doi="10.17487/RFC0506", + } + +@misc{rfc508, + author="L. Pfeifer and J. McAfee", + title="{Real-time data transmission on the ARPANET}", + howpublished="RFC 508", + series="Internet Request for Comments", + type="RFC", + number="508", + pages="1--10", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc508.txt", + key="RFC 508", + doi="10.17487/RFC0508", + } + +@misc{rfc509, + author="A.M. McKenzie", + title="{Traffic statistics (April 1973)}", + howpublished="RFC 509", + series="Internet Request for Comments", + type="RFC", + number="509", + pages="1--4", + year=1973, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc509.txt", + key="RFC 509", + doi="10.17487/RFC0509", + } + +@misc{rfc510, + author="J.E. White", + title="{Request for network mailbox addresses}", + howpublished="RFC 510", + series="Internet Request for Comments", + type="RFC", + number="510", + pages="1--2", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc510.txt", + key="RFC 510", + doi="10.17487/RFC0510", + } + +@misc{rfc511, + author="J.B. North", + title="{Enterprise phone service to NIC from ARPANET sites}", + howpublished="RFC 511", + series="Internet Request for Comments", + type="RFC", + number="511", + pages="1--4", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc511.txt", + key="RFC 511", + doi="10.17487/RFC0511", + } + +@misc{rfc512, + author="W. Hathaway", + title="{More on lost message detection}", + howpublished="RFC 512", + series="Internet Request for Comments", + type="RFC", + number="512", + pages="1--2", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc512.txt", + key="RFC 512", + doi="10.17487/RFC0512", + } + +@misc{rfc513, + author="W. Hathaway", + title="{Comments on the new Telnet specifications}", + howpublished="RFC 513", + series="Internet Request for Comments", + type="RFC", + number="513", + pages="1--3", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc513.txt", + key="RFC 513", + doi="10.17487/RFC0513", + } + +@misc{rfc514, + author="W. Kantrowitz", + title="{Network make-work}", + howpublished="RFC 514", + series="Internet Request for Comments", + type="RFC", + number="514", + pages="1--4", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc514.txt", + key="RFC 514", + doi="10.17487/RFC0514", + } + +@misc{rfc515, + author="R. Winter", + title="{Specifications for Datalanguage, Version 0/9}", + howpublished="RFC 515", + series="Internet Request for Comments", + type="RFC", + number="515", + pages="1--31", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc515.txt", + key="RFC 515", + doi="10.17487/RFC0515", + } + +@misc{rfc516, + author="J. Postel", + title="{Lost message detection}", + howpublished="RFC 516", + series="Internet Request for Comments", + type="RFC", + number="516", + pages="1--2", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc516.txt", + key="RFC 516", + doi="10.17487/RFC0516", + } + +@misc{rfc518, + author="N. Vaughan and E.J. Feinler", + title="{ARPANET accounts}", + howpublished="RFC 518", + series="Internet Request for Comments", + type="RFC", + number="518", + pages="1--9", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc518.txt", + key="RFC 518", + doi="10.17487/RFC0518", + } + +@misc{rfc519, + author="J.R. Pickens", + title="{Resource Evaluation}", + howpublished="RFC 519", + series="Internet Request for Comments", + type="RFC", + number="519", + pages="1--4", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc519.txt", + key="RFC 519", + doi="10.17487/RFC0519", + } + +@misc{rfc520, + author="J.D. Day", + title="{Memo to FTP group: Proposal for File Access Protocol}", + howpublished="RFC 520", + series="Internet Request for Comments", + type="RFC", + number="520", + pages="1--8", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc520.txt", + key="RFC 520", + doi="10.17487/RFC0520", + } + +@misc{rfc521, + author="A.M. McKenzie", + title="{Restricted use of IMP DDT}", + howpublished="RFC 521", + series="Internet Request for Comments", + type="RFC", + number="521", + pages="1--2", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc521.txt", + key="RFC 521", + doi="10.17487/RFC0521", + } + +@misc{rfc522, + author="A.M. McKenzie", + title="{Traffic Statistics (May 1973)}", + howpublished="RFC 522", + series="Internet Request for Comments", + type="RFC", + number="522", + pages="1--4", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc522.txt", + key="RFC 522", + doi="10.17487/RFC0522", + } + +@misc{rfc523, + author="A.K. Bhushan", + title="{SURVEY is in operation again}", + howpublished="RFC 523", + series="Internet Request for Comments", + type="RFC", + number="523", + pages="1--2", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc523.txt", + key="RFC 523", + doi="10.17487/RFC0523", + } + +@misc{rfc524, + author="J.E. White", + title="{Proposed Mail Protocol}", + howpublished="RFC 524", + series="Internet Request for Comments", + type="RFC", + number="524", + pages="1--40", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc524.txt", + key="RFC 524", + doi="10.17487/RFC0524", + } + +@misc{rfc525, + author="W. Parrish and J.R. Pickens", + title="{MIT-MATHLAB meets UCSB-OLS -an example of resource sharing}", + howpublished="RFC 525", + series="Internet Request for Comments", + type="RFC", + number="525", + pages="1--9", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc525.txt", + key="RFC 525", + doi="10.17487/RFC0525", + } + +@misc{rfc526, + author="W.K. Pratt", + title="{Technical meeting: Digital image processing software systems}", + howpublished="RFC 526", + series="Internet Request for Comments", + type="RFC", + number="526", + pages="1--3", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc526.txt", + key="RFC 526", + doi="10.17487/RFC0526", + } + +@misc{rfc527, + author="R. Merryman", + title="{ARPAWOCKY}", + howpublished="RFC 527", + series="Internet Request for Comments", + type="RFC", + number="527", + pages="1--1", + year=1973, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc527.txt", + key="RFC 527", + doi="10.17487/RFC0527", + } + +@misc{rfc528, + author="J.M. McQuillan", + title="{Software checksumming in the IMP and network reliability}", + howpublished="RFC 528", + series="Internet Request for Comments", + type="RFC", + number="528", + pages="1--9", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc528.txt", + key="RFC 528", + doi="10.17487/RFC0528", + } + +@misc{rfc529, + author="A.M. McKenzie and R. Thomas and R.S. Tomlinson and K.T. Pogran", + title="{Note on protocol synch sequences}", + howpublished="RFC 529", + series="Internet Request for Comments", + type="RFC", + number="529", + pages="1--4", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc529.txt", + key="RFC 529", + doi="10.17487/RFC0529", + } + +@misc{rfc530, + author="A.K. Bhushan", + title="{Report on the Survey Project}", + howpublished="RFC 530", + series="Internet Request for Comments", + type="RFC", + number="530", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc530.txt", + key="RFC 530", + doi="10.17487/RFC0530", + } + +@misc{rfc531, + author="M.A. Padlipsky", + title="{Feast or famine? A response to two recent RFC's about network information}", + howpublished="RFC 531", + series="Internet Request for Comments", + type="RFC", + number="531", + pages="1--2", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc531.txt", + key="RFC 531", + doi="10.17487/RFC0531", + } + +@misc{rfc532, + author="R.G. Merryman", + title="{UCSD-CC Server-FTP facility}", + howpublished="RFC 532", + series="Internet Request for Comments", + type="RFC", + number="532", + pages="1--4", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc532.txt", + key="RFC 532", + keywords="FTP, server", + doi="10.17487/RFC0532", + } + +@misc{rfc533, + author="D.C. Walden", + title="{Message-ID numbers}", + howpublished="RFC 533", + series="Internet Request for Comments", + type="RFC", + number="533", + pages="1--1", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc533.txt", + key="RFC 533", + doi="10.17487/RFC0533", + } + +@misc{rfc534, + author="D.C. Walden", + title="{Lost message detection}", + howpublished="RFC 534", + series="Internet Request for Comments", + type="RFC", + number="534", + pages="1--2", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc534.txt", + key="RFC 534", + doi="10.17487/RFC0534", + } + +@misc{rfc535, + author="R. Thomas", + title="{Comments on File Access Protocol}", + howpublished="RFC 535", + series="Internet Request for Comments", + type="RFC", + number="535", + pages="1--4", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc535.txt", + key="RFC 535", + doi="10.17487/RFC0535", + } + +@misc{rfc537, + author="S. Bunch", + title="{Announcement of NGG meeting July 16-17}", + howpublished="RFC 537", + series="Internet Request for Comments", + type="RFC", + number="537", + pages="1--2", + year=1973, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc537.txt", + key="RFC 537", + doi="10.17487/RFC0537", + } + +@misc{rfc538, + author="A.M. McKenzie", + title="{Traffic statistics (June 1973)}", + howpublished="RFC 538", + series="Internet Request for Comments", + type="RFC", + number="538", + pages="1--4", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 556", +url="https://www.rfc-editor.org/rfc/rfc538.txt", + key="RFC 538", + doi="10.17487/RFC0538", + } + +@misc{rfc539, + author="D. Crocker and J. Postel", + title="{Thoughts on the mail protocol proposed in RFC 524}", + howpublished="RFC 539", + series="Internet Request for Comments", + type="RFC", + number="539", + pages="1--3", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc539.txt", + key="RFC 539", + doi="10.17487/RFC0539", + } + +@misc{rfc542, + author="N. Neigus", + title="{File Transfer Protocol}", + howpublished="RFC 542", + series="Internet Request for Comments", + type="RFC", + number="542", + pages="1--40", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 765, updated by RFCs 614, 640", +url="https://www.rfc-editor.org/rfc/rfc542.txt", + key="RFC 542", + keywords="FTP", + doi="10.17487/RFC0542", + } + +@misc{rfc543, + author="N.D. Meyer", + title="{Network journal submission and delivery}", + howpublished="RFC 543", + series="Internet Request for Comments", + type="RFC", + number="543", + pages="1--8", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc543.txt", + key="RFC 543", + doi="10.17487/RFC0543", + } + +@misc{rfc544, + author="N.D. Meyer and K. Kelley", + title="{Locating on-line documentation at SRI-ARC}", + howpublished="RFC 544", + series="Internet Request for Comments", + type="RFC", + number="544", + pages="1--1", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc544.txt", + key="RFC 544", + doi="10.17487/RFC0544", + } + +@misc{rfc545, + author="J.R. Pickens", + title="{Of what quality be the UCSB resources evaluators?}", + howpublished="RFC 545", + series="Internet Request for Comments", + type="RFC", + number="545", + pages="1--2", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc545.txt", + key="RFC 545", + doi="10.17487/RFC0545", + } + +@misc{rfc546, + author="R. Thomas", + title="{Tenex load averages for July 1973}", + howpublished="RFC 546", + series="Internet Request for Comments", + type="RFC", + number="546", + pages="1--4", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc546.txt", + key="RFC 546", + doi="10.17487/RFC0546", + } + +@misc{rfc547, + author="D.C. Walden", + title="{Change to the Very Distant Host specification}", + howpublished="RFC 547", + series="Internet Request for Comments", + type="RFC", + number="547", + pages="1--3", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc547.txt", + key="RFC 547", + doi="10.17487/RFC0547", + } + +@misc{rfc548, + author="D.C. Walden", + title="{Hosts using the IMP Going Down message}", + howpublished="RFC 548", + series="Internet Request for Comments", + type="RFC", + number="548", + pages="1--1", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc548.txt", + key="RFC 548", + doi="10.17487/RFC0548", + } + +@misc{rfc549, + author="J.C. Michener", + title="{Minutes of Network Graphics Group meeting, 15-17 July 1973}", + howpublished="RFC 549", + series="Internet Request for Comments", + type="RFC", + number="549", + pages="1--12", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc549.txt", + key="RFC 549", + doi="10.17487/RFC0549", + } + +@misc{rfc550, + author="L.P. Deutsch", + title="{NIC NCP experiment}", + howpublished="RFC 550", + series="Internet Request for Comments", + type="RFC", + number="550", + pages="1--2", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc550.txt", + key="RFC 550", + doi="10.17487/RFC0550", + } + +@misc{rfc551, + author="Y. Feinroth and R. Fink", + title="{NYU, ANL, and LBL Joining the Net}", + howpublished="RFC 551", + series="Internet Request for Comments", + type="RFC", + number="551", + pages="1--2", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc551.txt", + key="RFC 551", + doi="10.17487/RFC0551", + } + +@misc{rfc552, + author="A.D. Owen", + title="{Single access to standard protocols}", + howpublished="RFC 552", + series="Internet Request for Comments", + type="RFC", + number="552", + pages="1--1", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc552.txt", + key="RFC 552", + doi="10.17487/RFC0552", + } + +@misc{rfc553, + author="C.H. Irby and K. Victor", + title="{Draft design for a text/graphics protocol}", + howpublished="RFC 553", + series="Internet Request for Comments", + type="RFC", + number="553", + pages="1--19", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc553.txt", + key="RFC 553", + doi="10.17487/RFC0553", + } + +@misc{rfc555, + author="J.E. White", + title="{Responses to critiques of the proposed mail protocol}", + howpublished="RFC 555", + series="Internet Request for Comments", + type="RFC", + number="555", + pages="1--11", + year=1973, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc555.txt", + key="RFC 555", + doi="10.17487/RFC0555", + } + +@misc{rfc556, + author="A.M. McKenzie", + title="{Traffic Statistics (July 1973)}", + howpublished="RFC 556", + series="Internet Request for Comments", + type="RFC", + number="556", + pages="1--4", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc556.txt", + key="RFC 556", + doi="10.17487/RFC0556", + } + +@misc{rfc557, + author="B.D. Wessler", + title="{REVELATIONS IN NETWORK HOST MEASUREMENTS}", + howpublished="RFC 557", + series="Internet Request for Comments", + type="RFC", + number="557", + pages="1--2", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc557.txt", + key="RFC 557", + doi="10.17487/RFC0557", + } + +@misc{rfc559, + author="A.K. Bushan", + title="{Comments on The New Telnet Protocol and its Implementation}", + howpublished="RFC 559", + series="Internet Request for Comments", + type="RFC", + number="559", + pages="1--5", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc559.txt", + key="RFC 559", + doi="10.17487/RFC0559", + } + +@misc{rfc560, + author="D. Crocker and J. Postel", + title="{Remote Controlled Transmission and Echoing Telnet option}", + howpublished="RFC 560", + series="Internet Request for Comments", + type="RFC", + number="560", + pages="1--12", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 581", +url="https://www.rfc-editor.org/rfc/rfc560.txt", + key="RFC 560", + doi="10.17487/RFC0560", + } + +@misc{rfc561, + author="A.K. Bhushan and K.T. Pogran and R.S. Tomlinson and J.E. White", + title="{Standardizing Network Mail Headers}", + howpublished="RFC 561", + series="Internet Request for Comments", + type="RFC", + number="561", + pages="1--3", + year=1973, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 680", +url="https://www.rfc-editor.org/rfc/rfc561.txt", + key="RFC 561", + doi="10.17487/RFC0561", + } + +@misc{rfc562, + author="A.M. McKenzie", + title="{Modifications to the TELNET Specification}", + howpublished="RFC 562", + series="Internet Request for Comments", + type="RFC", + number="562", + pages="1--2", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc562.txt", + key="RFC 562", + doi="10.17487/RFC0562", + } + +@misc{rfc563, + author="J. Davidson", + title="{Comments on the RCTE Telnet option}", + howpublished="RFC 563", + series="Internet Request for Comments", + type="RFC", + number="563", + pages="1--5", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc563.txt", + key="RFC 563", + doi="10.17487/RFC0563", + } + +@misc{rfc565, + author="D. Cantor", + title="{Storing network survey data at the datacomputer}", + howpublished="RFC 565", + series="Internet Request for Comments", + type="RFC", + number="565", + pages="1--5", + year=1973, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc565.txt", + key="RFC 565", + doi="10.17487/RFC0565", + } + +@misc{rfc566, + author="A.M. McKenzie", + title="{Traffic statistics (August 1973)}", + howpublished="RFC 566", + series="Internet Request for Comments", + type="RFC", + number="566", + pages="1--4", + year=1973, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 579", +url="https://www.rfc-editor.org/rfc/rfc566.txt", + key="RFC 566", + doi="10.17487/RFC0566", + } + +@misc{rfc567, + author="L.P. Deutsch", + title="{Cross Country Network Bandwidth}", + howpublished="RFC 567", + series="Internet Request for Comments", + type="RFC", + number="567", + pages="1--1", + year=1973, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 568", +url="https://www.rfc-editor.org/rfc/rfc567.txt", + key="RFC 567", + doi="10.17487/RFC0567", + } + +@misc{rfc568, + author="J.M. McQuillan", + title="{Response to RFC 567 - cross country network bandwidth}", + howpublished="RFC 568", + series="Internet Request for Comments", + type="RFC", + number="568", + pages="1--3", + year=1973, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc568.txt", + key="RFC 568", + doi="10.17487/RFC0568", + } + +@misc{rfc569, + author="M.A. Padlipsky", + title="{NETED: A Common Editor for the ARPA Network}", + howpublished="RFC 569 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="569", + pages="1--6", + year=1973, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc569.txt", + key="RFC 569", + keywords="NETED", + doi="10.17487/RFC0569", + } + +@misc{rfc570, + author="J.R. Pickens", + title="{Experimental input mapping between NVT ASCII and UCSB On Line System}", + howpublished="RFC 570", + series="Internet Request for Comments", + type="RFC", + number="570", + pages="1--1", + year=1973, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc570.txt", + key="RFC 570", + doi="10.17487/RFC0570", + } + +@misc{rfc571, + author="R. Braden", + title="{TENEX FTP PROBLEM}", + howpublished="RFC 571", + series="Internet Request for Comments", + type="RFC", + number="571", + pages="1--1", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc571.txt", + key="RFC 571", + doi="10.17487/RFC0571", + } + +@misc{rfc573, + author="A. Bhushan", + title="{DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS}", + howpublished="RFC 573", + series="Internet Request for Comments", + type="RFC", + number="573", + pages="1--8", + year=1973, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc573.txt", + key="RFC 573", + doi="10.17487/RFC0573", + } + +@misc{rfc574, + author="M. Krilanovich", + title="{Announcement of a Mail Facility at UCSB}", + howpublished="RFC 574", + series="Internet Request for Comments", + type="RFC", + number="574", + pages="1--1", + year=1973, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc574.txt", + key="RFC 574", + doi="10.17487/RFC0574", + } + +@misc{rfc576, + author="K. Victor", + title="{Proposal for modifying linking}", + howpublished="RFC 576", + series="Internet Request for Comments", + type="RFC", + number="576", + pages="1--2", + year=1973, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc576.txt", + key="RFC 576", + doi="10.17487/RFC0576", + } + +@misc{rfc577, + author="D. Crocker", + title="{Mail priority}", + howpublished="RFC 577", + series="Internet Request for Comments", + type="RFC", + number="577", + pages="1--2", + year=1973, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc577.txt", + key="RFC 577", + doi="10.17487/RFC0577", + } + +@misc{rfc578, + author="A.K. Bhushan and N.D. Ryan", + title="{Using MIT-Mathlab MACSYMA from MIT-DMS Muddle}", + howpublished="RFC 578", + series="Internet Request for Comments", + type="RFC", + number="578", + pages="1--9", + year=1973, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc578.txt", + key="RFC 578", + doi="10.17487/RFC0578", + } + +@misc{rfc579, + author="A.M. McKenzie", + title="{Traffic statistics (September 1973)}", + howpublished="RFC 579", + series="Internet Request for Comments", + type="RFC", + number="579", + pages="1--5", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 586", +url="https://www.rfc-editor.org/rfc/rfc579.txt", + key="RFC 579", + doi="10.17487/RFC0579", + } + +@misc{rfc580, + author="J. Postel", + title="{Note to Protocol Designers and Implementers}", + howpublished="RFC 580", + series="Internet Request for Comments", + type="RFC", + number="580", + pages="1--1", + year=1973, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 582", +url="https://www.rfc-editor.org/rfc/rfc580.txt", + key="RFC 580", + doi="10.17487/RFC0580", + } + +@misc{rfc581, + author="D. Crocker and J. Postel", + title="{Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option}", + howpublished="RFC 581", + series="Internet Request for Comments", + type="RFC", + number="581", + pages="1--5", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc581.txt", + key="RFC 581", + doi="10.17487/RFC0581", + } + +@misc{rfc582, + author="R. Clements", + title="{Comments on RFC 580: Machine readable protocols}", + howpublished="RFC 582", + series="Internet Request for Comments", + type="RFC", + number="582", + pages="1--1", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc582.txt", + key="RFC 582", + doi="10.17487/RFC0582", + } + +@misc{rfc584, + author="J. Iseli and D. Crocker and N. Neigus", + title="{Charter for ARPANET Users Interest Working Group}", + howpublished="RFC 584", + series="Internet Request for Comments", + type="RFC", + number="584", + pages="1--3", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc584.txt", + key="RFC 584", + doi="10.17487/RFC0584", + } + +@misc{rfc585, + author="D. Crocker and N. Neigus and E.J. Feinler and J. Iseli", + title="{ARPANET users interest working group meeting}", + howpublished="RFC 585", + series="Internet Request for Comments", + type="RFC", + number="585", + pages="1--9", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc585.txt", + key="RFC 585", + doi="10.17487/RFC0585", + } + +@misc{rfc586, + author="A.M. McKenzie", + title="{Traffic statistics (October 1973)}", + howpublished="RFC 586", + series="Internet Request for Comments", + type="RFC", + number="586", + pages="1--5", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc586.txt", + key="RFC 586", + doi="10.17487/RFC0586", + } + +@misc{rfc587, + author="J. Postel", + title="{Announcing New Telnet Options}", + howpublished="RFC 587", + series="Internet Request for Comments", + type="RFC", + number="587", + pages="1--1", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc587.txt", + key="RFC 587", + doi="10.17487/RFC0587", + } + +@misc{rfc588, + author="A. Stokes", + title="{London Node Is Now Up}", + howpublished="RFC 588", + series="Internet Request for Comments", + type="RFC", + number="588", + pages="1--3", + year=1973, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc588.txt", + key="RFC 588", + doi="10.17487/RFC0588", + } + +@misc{rfc589, + author="R.T. Braden", + title="{CCN NETRJS server messages to remote user}", + howpublished="RFC 589", + series="Internet Request for Comments", + type="RFC", + number="589", + pages="1--5", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc589.txt", + key="RFC 589", + doi="10.17487/RFC0589", + } + +@misc{rfc590, + author="M.A. Padlipsky", + title="{MULTICS address change}", + howpublished="RFC 590", + series="Internet Request for Comments", + type="RFC", + number="590", + pages="1--1", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc590.txt", + key="RFC 590", + doi="10.17487/RFC0590", + } + +@misc{rfc591, + author="D.C. Walden", + title="{Addition to the Very Distant Host specifications}", + howpublished="RFC 591", + series="Internet Request for Comments", + type="RFC", + number="591", + pages="1--1", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc591.txt", + key="RFC 591", + doi="10.17487/RFC0591", + } + +@misc{rfc592, + author="R.W. Watson", + title="{Some thoughts on system design to facilitate resource sharing}", + howpublished="RFC 592", + series="Internet Request for Comments", + type="RFC", + number="592", + pages="1--5", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc592.txt", + key="RFC 592", + doi="10.17487/RFC0592", + } + +@misc{rfc593, + author="A.M. McKenzie and J. Postel", + title="{Telnet and FTP implementation schedule change}", + howpublished="RFC 593", + series="Internet Request for Comments", + type="RFC", + number="593", + pages="1--1", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc593.txt", + key="RFC 593", + doi="10.17487/RFC0593", + } + +@misc{rfc594, + author="J.D. Burchfiel", + title="{Speedup of Host-IMP interface}", + howpublished="RFC 594", + series="Internet Request for Comments", + type="RFC", + number="594", + pages="1--3", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc594.txt", + key="RFC 594", + doi="10.17487/RFC0594", + } + +@misc{rfc595, + author="W. Hathaway", + title="{Second thoughts in defense of the Telnet Go-Ahead}", + howpublished="RFC 595", + series="Internet Request for Comments", + type="RFC", + number="595", + pages="1--5", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc595.txt", + key="RFC 595", + doi="10.17487/RFC0595", + } + +@misc{rfc596, + author="E.A. Taft", + title="{Second thoughts on Telnet Go-Ahead}", + howpublished="RFC 596", + series="Internet Request for Comments", + type="RFC", + number="596", + pages="1--5", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc596.txt", + key="RFC 596", + doi="10.17487/RFC0596", + } + +@misc{rfc597, + author="N. Neigus and E.J. Feinler", + title="{Host status}", + howpublished="RFC 597", + series="Internet Request for Comments", + type="RFC", + number="597", + pages="1--6", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 603", +url="https://www.rfc-editor.org/rfc/rfc597.txt", + key="RFC 597", + doi="10.17487/RFC0597", + } + +@misc{rfc598, + author="Network Information Center. Stanford Research Institute", + title="{RFC index - December 5, 1973}", + howpublished="RFC 598", + series="Internet Request for Comments", + type="RFC", + number="598", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc598.txt", + key="RFC 598", + doi="10.17487/RFC0598", + } + +@misc{rfc599, + author="R.T. Braden", + title="{Update on NETRJS}", + howpublished="RFC 599", + series="Internet Request for Comments", + type="RFC", + number="599", + pages="1--9", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 740", +url="https://www.rfc-editor.org/rfc/rfc599.txt", + key="RFC 599", + doi="10.17487/RFC0599", + } + +@misc{rfc600, + author="A. Berggreen", + title="{Interfacing an Illinois plasma terminal to the ARPANET}", + howpublished="RFC 600", + series="Internet Request for Comments", + type="RFC", + number="600", + pages="1--3", + year=1973, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc600.txt", + key="RFC 600", + abstract={Discusses some unusual interface issues for the Plato terminal.}, + doi="10.17487/RFC0600", + } + +@misc{rfc601, + author="A.M. McKenzie", + title="{Traffic statistics (November 1973)}", + howpublished="RFC 601", + series="Internet Request for Comments", + type="RFC", + number="601", + pages="1--5", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc601.txt", + key="RFC 601", + doi="10.17487/RFC0601", + } + +@misc{rfc602, + author="R.M. Metcalfe", + title="{``The stockings were hung by the chimney with care''}", + howpublished="RFC 602", + series="Internet Request for Comments", + type="RFC", + number="602", + pages="1--1", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc602.txt", + key="RFC 602", + abstract={Susceptibility of ARPANET to security violations.}, + keywords="security, violations, TIP, arpanet", + doi="10.17487/RFC0602", + } + +@misc{rfc603, + author="J.D. Burchfiel", + title="{Response to RFC 597: Host status}", + howpublished="RFC 603", + series="Internet Request for Comments", + type="RFC", + number="603", + pages="1--1", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 613", +url="https://www.rfc-editor.org/rfc/rfc603.txt", + key="RFC 603", + abstract={Questions about the ARPANET topology described in RFC 597.}, + doi="10.17487/RFC0603", + } + +@misc{rfc604, + author="J. Postel", + title="{Assigned link numbers}", + howpublished="RFC 604", + series="Internet Request for Comments", + type="RFC", + number="604", + pages="1--2", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 739", +url="https://www.rfc-editor.org/rfc/rfc604.txt", + key="RFC 604", + abstract={Modifies official host-host protocol. Replaces RFC 377.}, + doi="10.17487/RFC0604", + } + +@misc{rfc606, + author="L.P. Deutsch", + title="{Host names on-line}", + howpublished="RFC 606", + series="Internet Request for Comments", + type="RFC", + number="606", + pages="1--3", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc606.txt", + key="RFC 606", + abstract={Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.}, + keywords="lists, names, host, addresses", + doi="10.17487/RFC0606", + } + +@misc{rfc607, + author="M. Krilanovich and G. Gregg", + title="{Comments on the File Transfer Protocol}", + howpublished="RFC 607", + series="Internet Request for Comments", + type="RFC", + number="607", + pages="1--3", + year=1974, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 624, updated by RFC 614", +url="https://www.rfc-editor.org/rfc/rfc607.txt", + key="RFC 607", + abstract={An old version; see RFC 624; see also RFCs 614, 542 and 640.}, + keywords="solutions, weakness, ftp", + doi="10.17487/RFC0607", + } + +@misc{rfc608, + author="M.D. Kudlick", + title="{Host names on-line}", + howpublished="RFC 608", + series="Internet Request for Comments", + type="RFC", + number="608", + pages="1--4", + year=1974, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 810", +url="https://www.rfc-editor.org/rfc/rfc608.txt", + key="RFC 608", + abstract={Response to RFC 606; see also RFCs 627, 625 and 623.}, + doi="10.17487/RFC0608", + } + +@misc{rfc609, + author="B. Ferguson", + title="{Statement of upcoming move of NIC/NLS service}", + howpublished="RFC 609", + series="Internet Request for Comments", + type="RFC", + number="609", + pages="1--2", + year=1974, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc609.txt", + key="RFC 609", + abstract={See also RFCs 621 and 620.}, + doi="10.17487/RFC0609", + } + +@misc{rfc610, + author="R. Winter and J. Hill and W. Greiff", + title="{Further datalanguage design concepts}", + howpublished="RFC 610", + series="Internet Request for Comments", + type="RFC", + number="610", + pages="1--88", + year=1973, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc610.txt", + key="RFC 610", + abstract={Preliminary results of the language design; a model for data languagea semantics; future considerations.}, + doi="10.17487/RFC0610", + } + +@misc{rfc611, + author="D.C. Walden", + title="{Two changes to the IMP/Host Protocol to improve user/network communications}", + howpublished="RFC 611", + series="Internet Request for Comments", + type="RFC", + number="611", + pages="1--4", + year=1974, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc611.txt", + key="RFC 611", + abstract={Expansion of Host-Going-Down and addition of Dead-Host-Status Message.}, + doi="10.17487/RFC0611", + } + +@misc{rfc612, + author="A.M. McKenzie", + title="{Traffic statistics (December 1973)}", + howpublished="RFC 612", + series="Internet Request for Comments", + type="RFC", + number="612", + pages="1--6", + year=1974, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc612.txt", + key="RFC 612", + doi="10.17487/RFC0612", + } + +@misc{rfc613, + author="A.M. McKenzie", + title="{Network connectivity: A response to RFC 603}", + howpublished="RFC 613", + series="Internet Request for Comments", + type="RFC", + number="613", + pages="1--1", + year=1974, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc613.txt", + key="RFC 613", + doi="10.17487/RFC0613", + } + +@misc{rfc614, + author="K.T. Pogran and N. Neigus", + title="{Response to RFC 607: ``Comments on the File Transfer Protocol''}", + howpublished="RFC 614", + series="Internet Request for Comments", + type="RFC", + number="614", + pages="1--3", + year=1974, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc614.txt", + key="RFC 614", + abstract={See also RFCs 624, 542 and 640.}, + keywords="ftp, weakness, solutions", + doi="10.17487/RFC0614", + } + +@misc{rfc615, + author="D. Crocker", + title="{Proposed Network Standard Data Pathname syntax}", + howpublished="RFC 615", + series="Internet Request for Comments", + type="RFC", + number="615", + pages="1--4", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 645", +url="https://www.rfc-editor.org/rfc/rfc615.txt", + key="RFC 615", + doi="10.17487/RFC0615", + } + +@misc{rfc616, + author="D. Walden", + title="{LATEST NETWORK MAPS}", + howpublished="RFC 616", + series="Internet Request for Comments", + type="RFC", + number="616", + pages="1--1", + year=1973, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc616.txt", + key="RFC 616", + keywords="Network, maps", + doi="10.17487/RFC0616", + } + +@misc{rfc617, + author="E.A. Taft", + title="{Note on socket number assignment}", + howpublished="RFC 617", + series="Internet Request for Comments", + type="RFC", + number="617", + pages="1--3", + year=1974, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc617.txt", + key="RFC 617", + abstract={Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.}, + keywords="telnet", + doi="10.17487/RFC0617", + } + +@misc{rfc618, + author="E.A. Taft", + title="{Few observations on NCP statistics}", + howpublished="RFC 618", + series="Internet Request for Comments", + type="RFC", + number="618", + pages="1--3", + year=1974, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc618.txt", + key="RFC 618", + abstract={Distribution of NCP and IMP message types by actual measurement.}, + doi="10.17487/RFC0618", + } + +@misc{rfc619, + author="W. Naylor and H. Opderbeck", + title="{Mean round-trip times in the ARPANET}", + howpublished="RFC 619", + series="Internet Request for Comments", + type="RFC", + number="619", + pages="1--14", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc619.txt", + key="RFC 619", + abstract={Actual measurements of round-trip times.}, + doi="10.17487/RFC0619", + } + +@misc{rfc620, + author="B. Ferguson", + title="{Request for monitor host table updates}", + howpublished="RFC 620", + series="Internet Request for Comments", + type="RFC", + number="620", + pages="1--1", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc620.txt", + key="RFC 620", + abstract={In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.}, + keywords="tenex", + doi="10.17487/RFC0620", + } + +@misc{rfc621, + author="M.D. Kudlick", + title="{NIC user directories at SRI ARC}", + howpublished="RFC 621", + series="Internet Request for Comments", + type="RFC", + number="621", + pages="1--1", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc621.txt", + key="RFC 621", + abstract={See also RFCs 620 and 609.}, + doi="10.17487/RFC0621", + } + +@misc{rfc622, + author="A.M. McKenzie", + title="{Scheduling IMP/TIP down time}", + howpublished="RFC 622", + series="Internet Request for Comments", + type="RFC", + number="622", + pages="1--3", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc622.txt", + key="RFC 622", + abstract={Modification of previous policy.}, + doi="10.17487/RFC0622", + } + +@misc{rfc623, + author="M. Krilanovich", + title="{Comments on on-line host name service}", + howpublished="RFC 623", + series="Internet Request for Comments", + type="RFC", + number="623", + pages="1--2", + year=1974, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc623.txt", + key="RFC 623", + abstract={See also RFCs 627, 625, 608 and 606.}, + doi="10.17487/RFC0623", + } + +@misc{rfc624, + author="M. Krilanovich and G. Gregg and W. Hathaway and J.E. White", + title="{Comments on the File Transfer Protocol}", + howpublished="RFC 624", + series="Internet Request for Comments", + type="RFC", + number="624", + pages="1--3", + year=1974, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc624.txt", + key="RFC 624", + abstract={Design changes and slight modifications. Replaces RFC 607; see also RFCs 614, 542 and 640.}, + keywords="ftp, telnet", + doi="10.17487/RFC0624", + } + +@misc{rfc625, + author="M.D. Kudlick and E.J. Feinler", + title="{On-line hostnames service}", + howpublished="RFC 625", + series="Internet Request for Comments", + type="RFC", + number="625", + pages="1--1", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc625.txt", + key="RFC 625", + abstract={See also RFCs 606, 608, 623 and 627.}, + doi="10.17487/RFC0625", + } + +@misc{rfc626, + author="L. Kleinrock and H. Opderbeck", + title="{On a possible lockup condition in IMP subnet due to message sequencing}", + howpublished="RFC 626", + series="Internet Request for Comments", + type="RFC", + number="626", + pages="1--5", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc626.txt", + key="RFC 626", + doi="10.17487/RFC0626", + } + +@misc{rfc627, + author="M.D. Kudlick and E.J. Feinler", + title="{ASCII text file of hostnames}", + howpublished="RFC 627", + series="Internet Request for Comments", + type="RFC", + number="627", + pages="1--1", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc627.txt", + key="RFC 627", + abstract={See also RFCs 606, 608, 623 and 625.}, + doi="10.17487/RFC0627", + } + +@misc{rfc628, + author="M.L. Keeney", + title="{Status of RFC numbers and a note on pre-assigned journal numbers}", + howpublished="RFC 628", + series="Internet Request for Comments", + type="RFC", + number="628", + pages="1--1", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc628.txt", + key="RFC 628", + doi="10.17487/RFC0628", + } + +@misc{rfc629, + author="J.B. North", + title="{Scenario for using the Network Journal}", + howpublished="RFC 629", + series="Internet Request for Comments", + type="RFC", + number="629", + pages="1--3", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc629.txt", + key="RFC 629", + doi="10.17487/RFC0629", + } + +@misc{rfc630, + author="J. Sussman", + title="{FTP error code usage for more reliable mail service}", + howpublished="RFC 630", + series="Internet Request for Comments", + type="RFC", + number="630", + pages="1--3", + year=1974, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc630.txt", + key="RFC 630", + abstract={Describes FTP reply-code usage in TENEX mail processing.}, + doi="10.17487/RFC0630", + } + +@misc{rfc631, + author="A. Danthine", + title="{International meeting on minicomputers and data communication: Call for papers}", + howpublished="RFC 631", + series="Internet Request for Comments", + type="RFC", + number="631", + pages="1--2", + year=1974, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc631.txt", + key="RFC 631", + doi="10.17487/RFC0631", + } + +@misc{rfc632, + author="H. Opderbeck", + title="{Throughput degradations for single packet messages}", + howpublished="RFC 632", + series="Internet Request for Comments", + type="RFC", + number="632", + pages="1--6", + year=1974, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc632.txt", + key="RFC 632", + doi="10.17487/RFC0632", + } + +@misc{rfc633, + author="A.M. McKenzie", + title="{IMP/TIP preventive maintenance schedule}", + howpublished="RFC 633", + series="Internet Request for Comments", + type="RFC", + number="633", + pages="1--4", + year=1974, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 638", +url="https://www.rfc-editor.org/rfc/rfc633.txt", + key="RFC 633", + abstract={An old version; see RFC 638.}, + doi="10.17487/RFC0633", + } + +@misc{rfc634, + author="A.M. McKenzie", + title="{Change in network address for Haskins Lab}", + howpublished="RFC 634", + series="Internet Request for Comments", + type="RFC", + number="634", + pages="1--1", + year=1974, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc634.txt", + key="RFC 634", + doi="10.17487/RFC0634", + } + +@misc{rfc635, + author="V. Cerf", + title="{Assessment of ARPANET protocols}", + howpublished="RFC 635", + series="Internet Request for Comments", + type="RFC", + number="635", + pages="1--1", + year=1974, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc635.txt", + key="RFC 635", + abstract={Theoretical and practical motivation for redesign. Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement.}, + doi="10.17487/RFC0635", + } + +@misc{rfc636, + author="J.D. Burchfiel and B. Cosell and R.S. Tomlinson and D.C. Walden", + title="{TIP/Tenex reliability improvements}", + howpublished="RFC 636", + series="Internet Request for Comments", + type="RFC", + number="636", + pages="1--8", + year=1974, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc636.txt", + key="RFC 636", + abstract={Obtaining/maintaining connections; recovery from lost connections; connection-state changes.}, + doi="10.17487/RFC0636", + } + +@misc{rfc637, + author="A.M. McKenzie", + title="{Change of network address for SU-DSL}", + howpublished="RFC 637", + series="Internet Request for Comments", + type="RFC", + number="637", + pages="1--1", + year=1974, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc637.txt", + key="RFC 637", + doi="10.17487/RFC0637", + } + +@misc{rfc638, + author="A.M. McKenzie", + title="{IMP/TIP preventive maintenance schedule}", + howpublished="RFC 638", + series="Internet Request for Comments", + type="RFC", + number="638", + pages="1--4", + year=1974, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc638.txt", + key="RFC 638", + abstract={Corrects RFC 633.}, + doi="10.17487/RFC0638", + } + +@misc{rfc640, + author="J. Postel", + title="{Revised FTP reply codes}", + howpublished="RFC 640", + series="Internet Request for Comments", + type="RFC", + number="640", + pages="1--17", + year=1974, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc640.txt", + key="RFC 640", + abstract={Updates RFC 542.}, + doi="10.17487/RFC0640", + } + +@misc{rfc642, + author="J.D. Burchfiel", + title="{Ready line philosophy and implementation}", + howpublished="RFC 642", + series="Internet Request for Comments", + type="RFC", + number="642", + pages="1--4", + year=1974, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc642.txt", + key="RFC 642", + doi="10.17487/RFC0642", + } + +@misc{rfc643, + author="E. Mader", + title="{Network Debugging Protocol}", + howpublished="RFC 643", + series="Internet Request for Comments", + type="RFC", + number="643", + pages="1--7", + year=1974, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc643.txt", + key="RFC 643", + abstract={To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.}, + doi="10.17487/RFC0643", + } + +@misc{rfc644, + author="R. Thomas", + title="{On the problem of signature authentication for network mail}", + howpublished="RFC 644", + series="Internet Request for Comments", + type="RFC", + number="644", + pages="1--3", + year=1974, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc644.txt", + key="RFC 644", + doi="10.17487/RFC0644", + } + +@misc{rfc645, + author="D. Crocker", + title="{Network Standard Data Specification syntax}", + howpublished="RFC 645", + series="Internet Request for Comments", + type="RFC", + number="645", + pages="1--9", + year=1974, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc645.txt", + key="RFC 645", + abstract={Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.}, + doi="10.17487/RFC0645", + } + +@misc{rfc647, + author="M.A. Padlipsky", + title="{Proposed protocol for connecting host computers to ARPA-like networks via front end processors}", + howpublished="RFC 647", + series="Internet Request for Comments", + type="RFC", + number="647", + pages="1--20", + year=1974, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc647.txt", + key="RFC 647", + abstract={Approaches to Front-End protocol processing using available hardware and software.}, + doi="10.17487/RFC0647", + } + +@misc{rfc651, + author="D. Crocker", + title="{Revised Telnet status option}", + howpublished="RFC 651", + series="Internet Request for Comments", + type="RFC", + number="651", + pages="1--2", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 859", +url="https://www.rfc-editor.org/rfc/rfc651.txt", + key="RFC 651", + doi="10.17487/RFC0651", + } + +@misc{rfc652, + author="D. Crocker", + title="{Telnet output carriage-return disposition option}", + howpublished="RFC 652 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="652", + pages="1--4", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc652.txt", + key="RFC 652", + keywords="TOPT-OCRD", + doi="10.17487/RFC0652", + } + +@misc{rfc653, + author="D. Crocker", + title="{Telnet output horizontal tabstops option}", + howpublished="RFC 653 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="653", + pages="1--1", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc653.txt", + key="RFC 653", + keywords="TOPT-OHT", + doi="10.17487/RFC0653", + } + +@misc{rfc654, + author="D. Crocker", + title="{Telnet output horizontal tab disposition option}", + howpublished="RFC 654 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="654", + pages="1--1", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc654.txt", + key="RFC 654", + keywords="TOPT-OHTD", + doi="10.17487/RFC0654", + } + +@misc{rfc655, + author="D. Crocker", + title="{Telnet output formfeed disposition option}", + howpublished="RFC 655 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="655", + pages="1--1", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc655.txt", + key="RFC 655", + keywords="TOPT-OFD", + doi="10.17487/RFC0655", + } + +@misc{rfc656, + author="D. Crocker", + title="{Telnet output vertical tabstops option}", + howpublished="RFC 656 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="656", + pages="1--1", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc656.txt", + key="RFC 656", + keywords="TOPT-OVT", + doi="10.17487/RFC0656", + } + +@misc{rfc657, + author="D. Crocker", + title="{Telnet output vertical tab disposition option}", + howpublished="RFC 657 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="657", + pages="1--1", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc657.txt", + key="RFC 657", + keywords="TOPT-OVTD", + doi="10.17487/RFC0657", + } + +@misc{rfc658, + author="D. Crocker", + title="{Telnet output linefeed disposition}", + howpublished="RFC 658 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="658", + pages="1--2", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc658.txt", + key="RFC 658", + keywords="TOPT-OLD", + doi="10.17487/RFC0658", + } + +@misc{rfc659, + author="J. Postel", + title="{Announcing additional Telnet options}", + howpublished="RFC 659", + series="Internet Request for Comments", + type="RFC", + number="659", + pages="1--1", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc659.txt", + key="RFC 659", + abstract={Options defined in RFCs 651-658.}, + doi="10.17487/RFC0659", + } + +@misc{rfc660, + author="D.C. Walden", + title="{Some changes to the IMP and the IMP/Host interface}", + howpublished="RFC 660", + series="Internet Request for Comments", + type="RFC", + number="660", + pages="1--1", + year=1974, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc660.txt", + key="RFC 660", + abstract={Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.}, + doi="10.17487/RFC0660", + } + +@misc{rfc661, + author="J. Postel", + title="{Protocol information}", + howpublished="RFC 661", + series="Internet Request for Comments", + type="RFC", + number="661", + pages="1--21", + year=1974, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 694", +url="https://www.rfc-editor.org/rfc/rfc661.txt", + key="RFC 661", + abstract={An old version; see RFC 694.}, + doi="10.17487/RFC0661", + } + +@misc{rfc662, + author="R. Kanodia", + title="{Performance improvement in ARPANET file transfers from Multics}", + howpublished="RFC 662", + series="Internet Request for Comments", + type="RFC", + number="662", + pages="1--2", + year=1974, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc662.txt", + key="RFC 662", + abstract={Experimenting with host output buffers to improve throughput.}, + doi="10.17487/RFC0662", + } + +@misc{rfc663, + author="R. Kanodia", + title="{Lost message detection and recovery protocol}", + howpublished="RFC 663", + series="Internet Request for Comments", + type="RFC", + number="663", + pages="1--22", + year=1974, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc663.txt", + key="RFC 663", + abstract={Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.}, + keywords="ARPANET, Host", + doi="10.17487/RFC0663", + } + +@misc{rfc666, + author="M.A. Padlipsky", + title="{Specification of the Unified User-Level Protocol}", + howpublished="RFC 666", + series="Internet Request for Comments", + type="RFC", + number="666", + pages="1--19", + year=1974, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc666.txt", + key="RFC 666", + abstract={Discusses and proposes a common command language.}, + doi="10.17487/RFC0666", + } + +@misc{rfc667, + author="S.G. Chipman", + title="{Host Ports}", + howpublished="RFC 667", + series="Internet Request for Comments", + type="RFC", + number="667", + pages="1--2", + year=1974, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc667.txt", + key="RFC 667", + abstract={Approved scheme to connect host ports to the network.}, + doi="10.17487/RFC0667", + } + +@misc{rfc669, + author="D.W. Dodds", + title="{November, 1974, survey of New-Protocol Telnet servers}", + howpublished="RFC 669", + series="Internet Request for Comments", + type="RFC", + number="669", + pages="1--3", + year=1974, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 679", +url="https://www.rfc-editor.org/rfc/rfc669.txt", + key="RFC 669", + abstract={An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679.}, + doi="10.17487/RFC0669", + } + +@misc{rfc671, + author="R. Schantz", + title="{Note on Reconnection Protocol}", + howpublished="RFC 671", + series="Internet Request for Comments", + type="RFC", + number="671", + pages="1--9", + year=1974, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc671.txt", + key="RFC 671", + abstract={Experience with implementation in RSEXEC context.}, + doi="10.17487/RFC0671", + } + +@misc{rfc672, + author="R. Schantz", + title="{Multi-site data collection facility}", + howpublished="RFC 672", + series="Internet Request for Comments", + type="RFC", + number="672", + pages="1--9", + year=1974, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc672.txt", + key="RFC 672", + abstract={Applicability of TIP/TENEX protocols beyond TIP accounting.}, + doi="10.17487/RFC0672", + } + +@misc{rfc674, + author="J. Postel and J.E. White", + title="{Procedure call documents: Version 2}", + howpublished="RFC 674", + series="Internet Request for Comments", + type="RFC", + number="674", + pages="1--6", + year=1974, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc674.txt", + key="RFC 674", + abstract={Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.}, + doi="10.17487/RFC0674", + } + +@misc{rfc675, + author="V. Cerf and Y. Dalal and C. Sunshine", + title="{Specification of Internet Transmission Control Program}", + howpublished="RFC 675 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="675", + pages="1--70", + year=1974, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc675.txt", + key="RFC 675", + abstract={The first detailed specification of TCP; see RFC 793.}, + doi="10.17487/RFC0675", + } + +@misc{rfc677, + author="P.R. Johnson and R. Thomas", + title="{Maintenance of duplicate databases}", + howpublished="RFC 677", + series="Internet Request for Comments", + type="RFC", + number="677", + pages="1--10", + year=1975, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc677.txt", + key="RFC 677", + doi="10.17487/RFC0677", + } + +@misc{rfc678, + author="J. Postel", + title="{Standard file formats}", + howpublished="RFC 678", + series="Internet Request for Comments", + type="RFC", + number="678", + pages="1--9", + year=1974, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc678.txt", + key="RFC 678", + abstract={For transmission of documents across different environments.}, + doi="10.17487/RFC0678", + } + +@misc{rfc679, + author="D.W. Dodds", + title="{February, 1975, survey of New-Protocol Telnet servers}", + howpublished="RFC 679", + series="Internet Request for Comments", + type="RFC", + number="679", + pages="1--3", + year=1975, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 703", +url="https://www.rfc-editor.org/rfc/rfc679.txt", + key="RFC 679", + abstract={An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703.}, + doi="10.17487/RFC0679", + } + +@misc{rfc680, + author="T.H. Myer and D.A. Henderson", + title="{Message Transmission Protocol}", + howpublished="RFC 680", + series="Internet Request for Comments", + type="RFC", + number="680", + pages="1--6", + year=1975, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc680.txt", + key="RFC 680", + abstract={Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.}, + doi="10.17487/RFC0680", + } + +@misc{rfc681, + author="S. Holmgren", + title="{Network UNIX}", + howpublished="RFC 681", + series="Internet Request for Comments", + type="RFC", + number="681", + pages="1--8", + year=1975, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc681.txt", + key="RFC 681", + abstract={Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.}, + doi="10.17487/RFC0681", + } + +@misc{rfc683, + author="R. Clements", + title="{FTPSRV - Tenex extension for paged files}", + howpublished="RFC 683", + series="Internet Request for Comments", + type="RFC", + number="683", + pages="1--3", + year=1975, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc683.txt", + key="RFC 683", + abstract={Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.}, + keywords="FTP, paged, file, transfer, Tenex", + doi="10.17487/RFC0683", + } + +@misc{rfc684, + author="R. Schantz", + title="{Commentary on procedure calling as a network protocol}", + howpublished="RFC 684", + series="Internet Request for Comments", + type="RFC", + number="684", + pages="1--9", + year=1975, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc684.txt", + key="RFC 684", + abstract={Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.}, + doi="10.17487/RFC0684", + } + +@misc{rfc685, + author="M. Beeler", + title="{Response time in cross network debugging}", + howpublished="RFC 685", + series="Internet Request for Comments", + type="RFC", + number="685", + pages="1--3", + year=1975, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc685.txt", + key="RFC 685", + abstract={The contribution of ARPANET communication to response time.}, + doi="10.17487/RFC0685", + } + +@misc{rfc686, + author="B. Harvey", + title="{Leaving well enough alone}", + howpublished="RFC 686", + series="Internet Request for Comments", + type="RFC", + number="686", + pages="1--9", + year=1975, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc686.txt", + key="RFC 686", + abstract={Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.}, + doi="10.17487/RFC0686", + } + +@misc{rfc687, + author="D.C. Walden", + title="{IMP/Host and Host/IMP Protocol changes}", + howpublished="RFC 687", + series="Internet Request for Comments", + type="RFC", + number="687", + pages="1--2", + year=1975, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 704, updated by RFC 690", +url="https://www.rfc-editor.org/rfc/rfc687.txt", + key="RFC 687", + abstract={Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.}, + doi="10.17487/RFC0687", + } + +@misc{rfc688, + author="D.C. Walden", + title="{Tentative schedule for the new Telnet implementation for the TIP}", + howpublished="RFC 688", + series="Internet Request for Comments", + type="RFC", + number="688", + pages="1--1", + year=1975, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc688.txt", + key="RFC 688", + doi="10.17487/RFC0688", + } + +@misc{rfc689, + author="R. Clements", + title="{Tenex NCP finite state machine for connections}", + howpublished="RFC 689", + series="Internet Request for Comments", + type="RFC", + number="689", + pages="1--5", + year=1975, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc689.txt", + key="RFC 689", + abstract={Describes the internal states of an NCP connection in the TENEX implementation.}, + doi="10.17487/RFC0689", + } + +@misc{rfc690, + author="J. Postel", + title="{Comments on the proposed Host/IMP Protocol changes}", + howpublished="RFC 690", + series="Internet Request for Comments", + type="RFC", + number="690", + pages="1--3", + year=1975, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 692", +url="https://www.rfc-editor.org/rfc/rfc690.txt", + key="RFC 690", + abstract={Comments on suggestions in RFC 687; see also RFCs 692 and 696.}, + doi="10.17487/RFC0690", + } + +@misc{rfc691, + author="B. Harvey", + title="{One more try on the FTP}", + howpublished="RFC 691", + series="Internet Request for Comments", + type="RFC", + number="691", + pages="1--14", + year=1975, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc691.txt", + key="RFC 691", + abstract={Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.}, + doi="10.17487/RFC0691", + } + +@misc{rfc692, + author="S.M. Wolfe", + title="{Comments on IMP/Host Protocol changes (RFCs 687 and 690)}", + howpublished="RFC 692", + series="Internet Request for Comments", + type="RFC", + number="692", + pages="1--2", + year=1975, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc692.txt", + key="RFC 692", + abstract={A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.}, + doi="10.17487/RFC0692", + } + +@misc{rfc694, + author="J. Postel", + title="{Protocol information}", + howpublished="RFC 694", + series="Internet Request for Comments", + type="RFC", + number="694", + pages="1--36", + year=1975, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc694.txt", + key="RFC 694", + abstract={References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.}, + doi="10.17487/RFC0694", + } + +@misc{rfc695, + author="M. Krilanovich", + title="{Official change in Host-Host Protocol}", + howpublished="RFC 695", + series="Internet Request for Comments", + type="RFC", + number="695", + pages="1--3", + year=1975, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc695.txt", + key="RFC 695", + abstract={Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.}, + doi="10.17487/RFC0695", + } + +@misc{rfc696, + author="V.G. Cerf", + title="{Comments on the IMP/Host and Host/IMP Protocol changes}", + howpublished="RFC 696", + series="Internet Request for Comments", + type="RFC", + number="696", + pages="1--2", + year=1975, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc696.txt", + key="RFC 696", + abstract={Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.}, + doi="10.17487/RFC0696", + } + +@misc{rfc697, + author="J. Lieb", + title="{CWD command of FTP}", + howpublished="RFC 697", + series="Internet Request for Comments", + type="RFC", + number="697", + pages="1--2", + year=1975, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc697.txt", + key="RFC 697", + abstract={Discusses FTP login access to ``files only'' directories.}, + doi="10.17487/RFC0697", + } + +@misc{rfc698, + author="T. Mock", + title="{Telnet extended ASCII option}", + howpublished="RFC 698 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="698", + pages="1--3", + year=1975, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5198", +url="https://www.rfc-editor.org/rfc/rfc698.txt", + key="RFC 698", + abstract={Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.}, + keywords="TOPT-EXT", + doi="10.17487/RFC0698", + } + +@misc{rfc699, + author="J. Postel and J. Vernon", + title="{Request For Comments summary notes: 600-699}", + howpublished="RFC 699 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="699", + pages="1--9", + year=1982, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc699.txt", + key="RFC 699", + doi="10.17487/RFC0699", + } + +@misc{rfc700, + author="E. Mader and W.W. Plummer and R.S. Tomlinson", + title="{Protocol experiment}", + howpublished="RFC 700 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="700", + pages="1--7", + year=1974, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc700.txt", + key="RFC 700", + doi="10.17487/RFC0700", + } + +@misc{rfc701, + author="D.W. Dodds", + title="{August, 1974, survey of New-Protocol Telnet servers}", + howpublished="RFC 701", + series="Internet Request for Comments", + type="RFC", + number="701", + pages="1--1", + year=1974, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 702", +url="https://www.rfc-editor.org/rfc/rfc701.txt", + key="RFC 701", + doi="10.17487/RFC0701", + } + +@misc{rfc702, + author="D.W. Dodds", + title="{September, 1974, survey of New-Protocol Telnet servers}", + howpublished="RFC 702", + series="Internet Request for Comments", + type="RFC", + number="702", + pages="1--3", + year=1974, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 669", +url="https://www.rfc-editor.org/rfc/rfc702.txt", + key="RFC 702", + doi="10.17487/RFC0702", + } + +@misc{rfc703, + author="D.W. Dodds", + title="{July, 1975, survey of New-Protocol Telnet Servers}", + howpublished="RFC 703", + series="Internet Request for Comments", + type="RFC", + number="703", + pages="1--3", + year=1975, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc703.txt", + key="RFC 703", + doi="10.17487/RFC0703", + } + +@misc{rfc704, + author="P.J. Santos", + title="{IMP/Host and Host/IMP Protocol change}", + howpublished="RFC 704", + series="Internet Request for Comments", + type="RFC", + number="704", + pages="1--2", + year=1975, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc704.txt", + key="RFC 704", + doi="10.17487/RFC0704", + } + +@misc{rfc705, + author="R.F. Bryan", + title="{Front-end Protocol B6700 version}", + howpublished="RFC 705", + series="Internet Request for Comments", + type="RFC", + number="705", + pages="1--39", + year=1975, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc705.txt", + key="RFC 705", + doi="10.17487/RFC0705", + } + +@misc{rfc706, + author="J. Postel", + title="{On the junk mail problem}", + howpublished="RFC 706", + series="Internet Request for Comments", + type="RFC", + number="706", + pages="1--1", + year=1975, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc706.txt", + key="RFC 706", + doi="10.17487/RFC0706", + } + +@misc{rfc707, + author="J.E. White", + title="{High-level framework for network-based resource sharing}", + howpublished="RFC 707", + series="Internet Request for Comments", + type="RFC", + number="707", + pages="1--29", + year=1975, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc707.txt", + key="RFC 707", + doi="10.17487/RFC0707", + } + +@misc{rfc708, + author="J.E. White", + title="{Elements of a Distributed Programming System}", + howpublished="RFC 708", + series="Internet Request for Comments", + type="RFC", + number="708", + pages="1--30", + year=1976, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc708.txt", + key="RFC 708", + doi="10.17487/RFC0708", + } + +@misc{rfc712, + author="J.E. Donnelley", + title="{Distributed Capability Computing System (DCCS)}", + howpublished="RFC 712", + series="Internet Request for Comments", + type="RFC", + number="712", + pages="1--17", + year=1976, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc712.txt", + key="RFC 712", + doi="10.17487/RFC0712", + } + +@misc{rfc713, + author="J. Haverty", + title="{MSDTP-Message Services Data Transmission Protocol}", + howpublished="RFC 713", + series="Internet Request for Comments", + type="RFC", + number="713", + pages="1--21", + year=1976, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc713.txt", + key="RFC 713", + doi="10.17487/RFC0713", + } + +@misc{rfc714, + author="A.M. McKenzie", + title="{Host-Host Protocol for an ARPANET-Type Network}", + howpublished="RFC 714", + series="Internet Request for Comments", + type="RFC", + number="714", + pages="1--22", + year=1976, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc714.txt", + key="RFC 714", + doi="10.17487/RFC0714", + } + +@misc{rfc716, + author="D.C. Walden and J. Levin", + title="{Interim Revision to Appendix F of BBN 1822}", + howpublished="RFC 716", + series="Internet Request for Comments", + type="RFC", + number="716", + pages="1--1", + year=1976, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc716.txt", + key="RFC 716", + doi="10.17487/RFC0716", + } + +@misc{rfc717, + author="J. Postel", + title="{Assigned Network Numbers}", + howpublished="RFC 717 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="717", + pages="1--1", + year=1976, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc717.txt", + key="RFC 717", + doi="10.17487/RFC0717", + } + +@misc{rfc718, + author="J. Postel", + title="{Comments on RCTE from the Tenex Implementation Experience}", + howpublished="RFC 718", + series="Internet Request for Comments", + type="RFC", + number="718", + pages="1--1", + year=1976, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc718.txt", + key="RFC 718", + doi="10.17487/RFC0718", + } + +@misc{rfc719, + author="J. Postel", + title="{Discussion on RCTE}", + howpublished="RFC 719", + series="Internet Request for Comments", + type="RFC", + number="719", + pages="1--1", + year=1976, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc719.txt", + key="RFC 719", + doi="10.17487/RFC0719", + } + +@misc{rfc720, + author="D. Crocker", + title="{Address Specification Syntax for Network Mail}", + howpublished="RFC 720", + series="Internet Request for Comments", + type="RFC", + number="720", + pages="1--3", + year=1976, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc720.txt", + key="RFC 720", + doi="10.17487/RFC0720", + } + +@misc{rfc721, + author="L.L. Garlick", + title="{Out-of-Band Control Signals in a Host-to-Host Protocol}", + howpublished="RFC 721 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="721", + pages="1--7", + year=1976, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc721.txt", + key="RFC 721", + doi="10.17487/RFC0721", + } + +@misc{rfc722, + author="J. Haverty", + title="{Thoughts on Interactions in Distributed Services}", + howpublished="RFC 722", + series="Internet Request for Comments", + type="RFC", + number="722", + pages="1--13", + year=1976, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc722.txt", + key="RFC 722", + doi="10.17487/RFC0722", + } + +@misc{rfc724, + author="D. Crocker and K.T. Pogran and J. Vittal and D.A. Henderson", + title="{Proposed official standard for the format of ARPA Network messages}", + howpublished="RFC 724", + series="Internet Request for Comments", + type="RFC", + number="724", + pages="1--36", + year=1977, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 733", +url="https://www.rfc-editor.org/rfc/rfc724.txt", + key="RFC 724", + doi="10.17487/RFC0724", + } + +@misc{rfc725, + author="J.D. Day and G.R. Grossman", + title="{RJE protocol for a resource sharing network}", + howpublished="RFC 725", + series="Internet Request for Comments", + type="RFC", + number="725", + pages="1--27", + year=1977, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc725.txt", + key="RFC 725", + doi="10.17487/RFC0725", + } + +@misc{rfc726, + author="J. Postel and D. Crocker", + title="{Remote Controlled Transmission and Echoing Telnet option}", + howpublished="RFC 726 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="726", + pages="1--16", + year=1977, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc726.txt", + key="RFC 726", + keywords="TOPT-REM", + doi="10.17487/RFC0726", + } + +@misc{rfc727, + author="M.R. Crispin", + title="{Telnet logout option}", + howpublished="RFC 727 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="727", + pages="1--3", + year=1977, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc727.txt", + key="RFC 727", + keywords="TOPT-LOGO", + doi="10.17487/RFC0727", + } + +@misc{rfc728, + author="J.D. Day", + title="{Minor pitfall in the Telnet Protocol}", + howpublished="RFC 728", + series="Internet Request for Comments", + type="RFC", + number="728", + pages="1--1", + year=1977, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc728.txt", + key="RFC 728", + doi="10.17487/RFC0728", + } + +@misc{rfc729, + author="D. Crocker", + title="{Telnet byte macro option}", + howpublished="RFC 729", + series="Internet Request for Comments", + type="RFC", + number="729", + pages="1--3", + year=1977, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 735", +url="https://www.rfc-editor.org/rfc/rfc729.txt", + key="RFC 729", + doi="10.17487/RFC0729", + } + +@misc{rfc730, + author="J. Postel", + title="{Extensible field addressing}", + howpublished="RFC 730", + series="Internet Request for Comments", + type="RFC", + number="730", + pages="1--5", + year=1977, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc730.txt", + key="RFC 730", + doi="10.17487/RFC0730", + } + +@misc{rfc731, + author="J.D. Day", + title="{Telnet Data Entry Terminal option}", + howpublished="RFC 731", + series="Internet Request for Comments", + type="RFC", + number="731", + pages="1--28", + year=1977, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 732", +url="https://www.rfc-editor.org/rfc/rfc731.txt", + key="RFC 731", + doi="10.17487/RFC0731", + } + +@misc{rfc732, + author="J.D. Day", + title="{Telnet Data Entry Terminal option}", + howpublished="RFC 732", + series="Internet Request for Comments", + type="RFC", + number="732", + pages="1--30", + year=1977, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1043", +url="https://www.rfc-editor.org/rfc/rfc732.txt", + key="RFC 732", + doi="10.17487/RFC0732", + } + +@misc{rfc733, + author="D. Crocker and J. Vittal and K.T. Pogran and D.A. Henderson", + title="{Standard for the format of ARPA network text messages}", + howpublished="RFC 733", + series="Internet Request for Comments", + type="RFC", + number="733", + pages="1--38", + year=1977, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 822", +url="https://www.rfc-editor.org/rfc/rfc733.txt", + key="RFC 733", + doi="10.17487/RFC0733", + } + +@misc{rfc734, + author="M.R. Crispin", + title="{SUPDUP Protocol}", + howpublished="RFC 734 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="734", + pages="1--13", + year=1977, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc734.txt", + key="RFC 734", + keywords="SUPDUP", + doi="10.17487/RFC0734", + } + +@misc{rfc735, + author="D. Crocker and R.H. Gumpertz", + title="{Revised Telnet byte macro option}", + howpublished="RFC 735 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="735", + pages="1--5", + year=1977, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc735.txt", + key="RFC 735", + keywords="TOPT-BYTE", + doi="10.17487/RFC0735", + } + +@misc{rfc736, + author="M.R. Crispin", + title="{Telnet SUPDUP option}", + howpublished="RFC 736 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="736", + pages="1--1", + year=1977, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc736.txt", + key="RFC 736", + keywords="TOPT-SUP", + doi="10.17487/RFC0736", + } + +@misc{rfc737, + author="K. Harrenstien", + title="{FTP extension: XSEN}", + howpublished="RFC 737", + series="Internet Request for Comments", + type="RFC", + number="737", + pages="1--1", + year=1977, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc737.txt", + key="RFC 737", + doi="10.17487/RFC0737", + } + +@misc{rfc738, + author="K. Harrenstien", + title="{Time server}", + howpublished="RFC 738", + series="Internet Request for Comments", + type="RFC", + number="738", + pages="1--1", + year=1977, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc738.txt", + key="RFC 738", + doi="10.17487/RFC0738", + } + +@misc{rfc739, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 739 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="739", + pages="1--11", + year=1977, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 750", +url="https://www.rfc-editor.org/rfc/rfc739.txt", + key="RFC 739", + doi="10.17487/RFC0739", + } + +@misc{rfc740, + author="R.T. Braden", + title="{NETRJS Protocol}", + howpublished="RFC 740 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="740", + pages="1--19", + year=1977, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc740.txt", + key="RFC 740", + keywords="NETRJS", + doi="10.17487/RFC0740", + } + +@misc{rfc741, + author="D. Cohen", + title="{Specifications for the Network Voice Protocol (NVP)}", + howpublished="RFC 741", + series="Internet Request for Comments", + type="RFC", + number="741", + pages="1--34", + year=1977, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc741.txt", + key="RFC 741", + doi="10.17487/RFC0741", + } + +@misc{rfc742, + author="K. Harrenstien", + title="{NAME/FINGER Protocol}", + howpublished="RFC 742", + series="Internet Request for Comments", + type="RFC", + number="742", + pages="1--7", + year=1977, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1288, 1196, 1194", +url="https://www.rfc-editor.org/rfc/rfc742.txt", + key="RFC 742", + doi="10.17487/RFC0742", + } + +@misc{rfc743, + author="K. Harrenstien", + title="{FTP extension: XRSQ/XRCP}", + howpublished="RFC 743", + series="Internet Request for Comments", + type="RFC", + number="743", + pages="1--8", + year=1977, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc743.txt", + key="RFC 743", + doi="10.17487/RFC0743", + } + +@misc{rfc744, + author="J. Sattley", + title="{MARS - a Message Archiving and Retrieval Service}", + howpublished="RFC 744", + series="Internet Request for Comments", + type="RFC", + number="744", + pages="1--6", + year=1978, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc744.txt", + key="RFC 744", + doi="10.17487/RFC0744", + } + +@misc{rfc745, + author="M. Beeler", + title="{JANUS interface specifications}", + howpublished="RFC 745", + series="Internet Request for Comments", + type="RFC", + number="745", + pages="1--10", + year=1978, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc745.txt", + key="RFC 745", + keywords="JANUS, interface, specifications", + doi="10.17487/RFC0745", + } + +@misc{rfc746, + author="R. Stallman", + title="{SUPDUP graphics extension}", + howpublished="RFC 746", + series="Internet Request for Comments", + type="RFC", + number="746", + pages="1--15", + year=1978, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc746.txt", + key="RFC 746", + doi="10.17487/RFC0746", + } + +@misc{rfc747, + author="M.R. Crispin", + title="{Recent extensions to the SUPDUP Protocol}", + howpublished="RFC 747", + series="Internet Request for Comments", + type="RFC", + number="747", + pages="1--1", + year=1978, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc747.txt", + key="RFC 747", + doi="10.17487/RFC0747", + } + +@misc{rfc748, + author="M.R. Crispin", + title="{Telnet randomly-lose option}", + howpublished="RFC 748", + series="Internet Request for Comments", + type="RFC", + number="748", + pages="1--2", + year=1978, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc748.txt", + key="RFC 748", + doi="10.17487/RFC0748", + } + +@misc{rfc749, + author="B. Greenberg", + title="{Telnet SUPDUP-Output option}", + howpublished="RFC 749 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="749", + pages="1--4", + year=1978, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc749.txt", + key="RFC 749", + keywords="TOPT-SUPO", + doi="10.17487/RFC0749", + } + +@misc{rfc750, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 750 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="750", + pages="1--12", + year=1978, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 755", +url="https://www.rfc-editor.org/rfc/rfc750.txt", + key="RFC 750", + doi="10.17487/RFC0750", + } + +@misc{rfc751, + author="P.D. Lebling", + title="{Survey of FTP mail and MLFL}", + howpublished="RFC 751", + series="Internet Request for Comments", + type="RFC", + number="751", + pages="1--5", + year=1978, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc751.txt", + key="RFC 751", + doi="10.17487/RFC0751", + } + +@misc{rfc752, + author="M.R. Crispin", + title="{Universal host table}", + howpublished="RFC 752", + series="Internet Request for Comments", + type="RFC", + number="752", + pages="1--12", + year=1979, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc752.txt", + key="RFC 752", + doi="10.17487/RFC0752", + } + +@misc{rfc753, + author="J. Postel", + title="{Internet Message Protocol}", + howpublished="RFC 753", + series="Internet Request for Comments", + type="RFC", + number="753", + pages="1--62", + year=1979, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc753.txt", + key="RFC 753", + doi="10.17487/RFC0753", + } + +@misc{rfc754, + author="J. Postel", + title="{Out-of-net host addresses for mail}", + howpublished="RFC 754", + series="Internet Request for Comments", + type="RFC", + number="754", + pages="1--10", + year=1979, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc754.txt", + key="RFC 754", + doi="10.17487/RFC0754", + } + +@misc{rfc755, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 755 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="755", + pages="1--12", + year=1979, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 758", +url="https://www.rfc-editor.org/rfc/rfc755.txt", + key="RFC 755", + doi="10.17487/RFC0755", + } + +@misc{rfc756, + author="J.R. Pickens and E.J. Feinler and J.E. Mathis", + title="{NIC name server - a datagram-based information utility}", + howpublished="RFC 756", + series="Internet Request for Comments", + type="RFC", + number="756", + pages="1--12", + year=1979, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc756.txt", + key="RFC 756", + doi="10.17487/RFC0756", + } + +@misc{rfc757, + author="D.P. Deutsch", + title="{Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems}", + howpublished="RFC 757", + series="Internet Request for Comments", + type="RFC", + number="757", + pages="1--19", + year=1979, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc757.txt", + key="RFC 757", + doi="10.17487/RFC0757", + } + +@misc{rfc758, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 758 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="758", + pages="1--12", + year=1979, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 762", +url="https://www.rfc-editor.org/rfc/rfc758.txt", + key="RFC 758", + doi="10.17487/RFC0758", + } + +@misc{rfc759, + author="J. Postel", + title="{Internet Message Protocol}", + howpublished="RFC 759 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="759", + pages="1--77", + year=1980, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc759.txt", + key="RFC 759", + keywords="MPM", + doi="10.17487/RFC0759", + } + +@misc{rfc760, + author="J. Postel", + title="{DoD standard Internet Protocol}", + howpublished="RFC 760", + series="Internet Request for Comments", + type="RFC", + number="760", + pages="1--46", + year=1980, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 791, updated by RFC 777", +url="https://www.rfc-editor.org/rfc/rfc760.txt", + key="RFC 760", + doi="10.17487/RFC0760", + } + +@misc{rfc761, + author="J. Postel", + title="{DoD standard Transmission Control Protocol}", + howpublished="RFC 761 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="761", + pages="1--88", + year=1980, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 793, 7805", +url="https://www.rfc-editor.org/rfc/rfc761.txt", + key="RFC 761", + keywords="TCP", + doi="10.17487/RFC0761", + } + +@misc{rfc762, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 762 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="762", + pages="1--13", + year=1980, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 770", +url="https://www.rfc-editor.org/rfc/rfc762.txt", + key="RFC 762", + doi="10.17487/RFC0762", + } + +@misc{rfc763, + author="M.D. Abrams", + title="{Role mailboxes}", + howpublished="RFC 763", + series="Internet Request for Comments", + type="RFC", + number="763", + pages="1--1", + year=1980, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc763.txt", + key="RFC 763", + doi="10.17487/RFC0763", + } + +@misc{rfc764, + author="J. Postel", + title="{Telnet Protocol specification}", + howpublished="RFC 764", + series="Internet Request for Comments", + type="RFC", + number="764", + pages="1--15", + year=1980, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 854", +url="https://www.rfc-editor.org/rfc/rfc764.txt", + key="RFC 764", + doi="10.17487/RFC0764", + } + +@misc{rfc765, + author="J. Postel", + title="{File Transfer Protocol specification}", + howpublished="RFC 765", + series="Internet Request for Comments", + type="RFC", + number="765", + pages="1--70", + year=1980, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 959", +url="https://www.rfc-editor.org/rfc/rfc765.txt", + key="RFC 765", + doi="10.17487/RFC0765", + } + +@misc{rfc766, + author="J. Postel", + title="{Internet Protocol Handbook: Table of contents}", + howpublished="RFC 766", + series="Internet Request for Comments", + type="RFC", + number="766", + pages="1--2", + year=1980, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 774", +url="https://www.rfc-editor.org/rfc/rfc766.txt", + key="RFC 766", + doi="10.17487/RFC0766", + } + +@misc{rfc767, + author="J. Postel", + title="{Structured format for transmission of multi-media documents}", + howpublished="RFC 767", + series="Internet Request for Comments", + type="RFC", + number="767", + pages="1--40", + year=1980, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc767.txt", + key="RFC 767", + doi="10.17487/RFC0767", + } + +@misc{rfc768, + author="J. Postel", + title="{User Datagram Protocol}", + howpublished="RFC 768 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="768", + pages="1--3", + year=1980, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc768.txt", + key="RFC 768", + keywords="UDP, UDP", + doi="10.17487/RFC0768", + } + +@misc{rfc769, + author="J. Postel", + title="{Rapicom 450 facsimile file format}", + howpublished="RFC 769", + series="Internet Request for Comments", + type="RFC", + number="769", + pages="1--2", + year=1980, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc769.txt", + key="RFC 769", + doi="10.17487/RFC0769", + } + +@misc{rfc770, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 770 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="770", + pages="1--15", + year=1980, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 776", +url="https://www.rfc-editor.org/rfc/rfc770.txt", + key="RFC 770", + doi="10.17487/RFC0770", + } + +@misc{rfc771, + author="V.G. Cerf and J. Postel", + title="{Mail transition plan}", + howpublished="RFC 771", + series="Internet Request for Comments", + type="RFC", + number="771", + pages="1--9", + year=1980, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc771.txt", + key="RFC 771", + doi="10.17487/RFC0771", + } + +@misc{rfc772, + author="S. Sluizer and J. Postel", + title="{Mail Transfer Protocol}", + howpublished="RFC 772", + series="Internet Request for Comments", + type="RFC", + number="772", + pages="1--31", + year=1980, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 780", +url="https://www.rfc-editor.org/rfc/rfc772.txt", + key="RFC 772", + keywords="MTP, email", + doi="10.17487/RFC0772", + } + +@misc{rfc773, + author="V.G. Cerf", + title="{Comments on NCP/TCP mail service transition strategy}", + howpublished="RFC 773", + series="Internet Request for Comments", + type="RFC", + number="773", + pages="1--11", + year=1980, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc773.txt", + key="RFC 773", + doi="10.17487/RFC0773", + } + +@misc{rfc774, + author="J. Postel", + title="{Internet Protocol Handbook: Table of contents}", + howpublished="RFC 774", + series="Internet Request for Comments", + type="RFC", + number="774", + pages="1--3", + year=1980, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc774.txt", + key="RFC 774", + doi="10.17487/RFC0774", + } + +@misc{rfc775, + author="D. Mankins and D. Franklin and A.D. Owen", + title="{Directory oriented FTP commands}", + howpublished="RFC 775", + series="Internet Request for Comments", + type="RFC", + number="775", + pages="1--6", + year=1980, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc775.txt", + key="RFC 775", + doi="10.17487/RFC0775", + } + +@misc{rfc776, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 776 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="776", + pages="1--13", + year=1981, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 790", +url="https://www.rfc-editor.org/rfc/rfc776.txt", + key="RFC 776", + doi="10.17487/RFC0776", + } + +@misc{rfc777, + author="J. Postel", + title="{Internet Control Message Protocol}", + howpublished="RFC 777", + series="Internet Request for Comments", + type="RFC", + number="777", + pages="1--14", + year=1981, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 792", +url="https://www.rfc-editor.org/rfc/rfc777.txt", + key="RFC 777", + doi="10.17487/RFC0777", + } + +@misc{rfc778, + author="D.L. Mills", + title="{DCNET Internet Clock Service}", + howpublished="RFC 778 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="778", + pages="1--4", + year=1981, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc778.txt", + key="RFC 778", + keywords="CLOCK", + doi="10.17487/RFC0778", + } + +@misc{rfc779, + author="E. Killian", + title="{Telnet send-location option}", + howpublished="RFC 779 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="779", + pages="1--2", + year=1981, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc779.txt", + key="RFC 779", + keywords="TOPT-SNDL", + doi="10.17487/RFC0779", + } + +@misc{rfc780, + author="S. Sluizer and J. Postel", + title="{Mail Transfer Protocol}", + howpublished="RFC 780", + series="Internet Request for Comments", + type="RFC", + number="780", + pages="1--47", + year=1981, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 788", +url="https://www.rfc-editor.org/rfc/rfc780.txt", + key="RFC 780", + keywords="MTP, email", + doi="10.17487/RFC0780", + } + +@misc{rfc781, + author="Z. Su", + title="{Specification of the Internet Protocol (IP) timestamp option}", + howpublished="RFC 781", + series="Internet Request for Comments", + type="RFC", + number="781", + pages="1--1", + year=1981, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc781.txt", + key="RFC 781", + doi="10.17487/RFC0781", + } + +@misc{rfc782, + author="J. Nabielsky and A.P. Skelton", + title="{Virtual Terminal management model}", + howpublished="RFC 782", + series="Internet Request for Comments", + type="RFC", + number="782", + pages="1--23", + year=1981, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc782.txt", + key="RFC 782", + doi="10.17487/RFC0782", + } + +@misc{rfc783, + author="K.R. Sollins", + title="{TFTP Protocol (revision 2)}", + howpublished="RFC 783", + series="Internet Request for Comments", + type="RFC", + number="783", + pages="1--18", + year=1981, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1350", +url="https://www.rfc-editor.org/rfc/rfc783.txt", + key="RFC 783", + doi="10.17487/RFC0783", + } + +@misc{rfc784, + author="S. Sluizer and J. Postel", + title="{Mail Transfer Protocol: ISI TOPS20 implementation}", + howpublished="RFC 784", + series="Internet Request for Comments", + type="RFC", + number="784", + pages="1--3", + year=1981, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc784.txt", + key="RFC 784", + keywords="MTP, email", + doi="10.17487/RFC0784", + } + +@misc{rfc785, + author="S. Sluizer and J. Postel", + title="{Mail Transfer Protocol: ISI TOPS20 file definitions}", + howpublished="RFC 785", + series="Internet Request for Comments", + type="RFC", + number="785", + pages="1--3", + year=1981, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc785.txt", + key="RFC 785", + keywords="MTP, email", + doi="10.17487/RFC0785", + } + +@misc{rfc786, + author="S. Sluizer and J. Postel", + title="{Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface}", + howpublished="RFC 786", + series="Internet Request for Comments", + type="RFC", + number="786", + pages="1--2", + year=1981, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc786.txt", + key="RFC 786", + keywords="MTP, NIMAIL, TOPS20", + doi="10.17487/RFC0786", + } + +@misc{rfc787, + author="A.L. Chapin", + title="{Connectionless data transmission survey/tutorial}", + howpublished="RFC 787", + series="Internet Request for Comments", + type="RFC", + number="787", + pages="1--40", + year=1981, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc787.txt", + key="RFC 787", + doi="10.17487/RFC0787", + } + +@misc{rfc788, + author="J. Postel", + title="{Simple Mail Transfer Protocol}", + howpublished="RFC 788", + series="Internet Request for Comments", + type="RFC", + number="788", + pages="1--64", + year=1981, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 821", +url="https://www.rfc-editor.org/rfc/rfc788.txt", + key="RFC 788", + keywords="SMTP, email", + doi="10.17487/RFC0788", + } + +@misc{rfc789, + author="E.C. Rosen", + title="{Vulnerabilities of network control protocols: An example}", + howpublished="RFC 789", + series="Internet Request for Comments", + type="RFC", + number="789", + pages="1--16", + year=1981, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc789.txt", + key="RFC 789", + doi="10.17487/RFC0789", + } + +@misc{rfc790, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 790 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="790", + pages="1--15", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 820", +url="https://www.rfc-editor.org/rfc/rfc790.txt", + key="RFC 790", + doi="10.17487/RFC0790", + } + +@misc{rfc791, + author="J. Postel", + title="{Internet Protocol}", + howpublished="RFC 791 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="791", + pages="1--51", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1349, 2474, 6864", +url="https://www.rfc-editor.org/rfc/rfc791.txt", + key="RFC 791", + keywords="IP, IPv4", + doi="10.17487/RFC0791", + } + +@misc{rfc792, + author="J. Postel", + title="{Internet Control Message Protocol}", + howpublished="RFC 792 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="792", + pages="1--21", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 950, 4884, 6633, 6918", +url="https://www.rfc-editor.org/rfc/rfc792.txt", + key="RFC 792", + keywords="ICMP", + doi="10.17487/RFC0792", + } + +@misc{rfc793, + author="J. Postel", + title="{Transmission Control Protocol}", + howpublished="RFC 793 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="793", + pages="1--91", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1122, 3168, 6093, 6528", +url="https://www.rfc-editor.org/rfc/rfc793.txt", + key="RFC 793", + keywords="TCP, TCP", + doi="10.17487/RFC0793", + } + +@misc{rfc794, + author="V.G. Cerf", + title="{Pre-emption}", + howpublished="RFC 794 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="794", + pages="1--2", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc794.txt", + key="RFC 794", + doi="10.17487/RFC0794", + } + +@misc{rfc795, + author="J. Postel", + title="{Service mappings}", + howpublished="RFC 795 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="795", + pages="1--4", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc795.txt", + key="RFC 795", + doi="10.17487/RFC0795", + } + +@misc{rfc796, + author="J. Postel", + title="{Address mappings}", + howpublished="RFC 796 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="796", + pages="1--7", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc796.txt", + key="RFC 796", + doi="10.17487/RFC0796", + } + +@misc{rfc797, + author="A.R. Katz", + title="{Format for Bitmap files}", + howpublished="RFC 797", + series="Internet Request for Comments", + type="RFC", + number="797", + pages="1--2", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc797.txt", + key="RFC 797", + doi="10.17487/RFC0797", + } + +@misc{rfc798, + author="A.R. Katz", + title="{Decoding facsimile data from the Rapicom 450}", + howpublished="RFC 798", + series="Internet Request for Comments", + type="RFC", + number="798", + pages="1--17", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc798.txt", + key="RFC 798", + doi="10.17487/RFC0798", + } + +@misc{rfc799, + author="D.L. Mills", + title="{Internet name domains}", + howpublished="RFC 799", + series="Internet Request for Comments", + type="RFC", + number="799", + pages="1--5", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc799.txt", + key="RFC 799", + doi="10.17487/RFC0799", + } + +@misc{rfc800, + author="J. Postel and J. Vernon", + title="{Request For Comments summary notes: 700-799}", + howpublished="RFC 800 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="800", + pages="1--10", + year=1982, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc800.txt", + key="RFC 800", + abstract={This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs.}, + doi="10.17487/RFC0800", + } + +@misc{rfc801, + author="J. Postel", + title="{NCP/TCP transition plan}", + howpublished="RFC 801", + series="Internet Request for Comments", + type="RFC", + number="801", + pages="1--21", + year=1981, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc801.txt", + key="RFC 801", + abstract={This RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.}, + doi="10.17487/RFC0801", + } + +@misc{rfc802, + author="A.G. Malis", + title="{ARPANET 1822L Host Access Protocol}", + howpublished="RFC 802", + series="Internet Request for Comments", + type="RFC", + number="802", + pages="1--45", + year=1981, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 851", +url="https://www.rfc-editor.org/rfc/rfc802.txt", + key="RFC 802", + abstract={This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851.}, + doi="10.17487/RFC0802", + } + +@misc{rfc803, + author="A. Agarwal and M.J. O'Connor and D.L. Mills", + title="{Dacom 450/500 facsimile data transcoding}", + howpublished="RFC 803", + series="Internet Request for Comments", + type="RFC", + number="803", + pages="1--14", + year=1981, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc803.txt", + key="RFC 803", + abstract={The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum. The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators.}, + doi="10.17487/RFC0803", + } + +@misc{rfc804, + author="International Telegraph and Telephone Consultative Committee of the International Telecommunication Union", + title="{CCITT draft recommendation T.4}", + howpublished="RFC 804", + series="Internet Request for Comments", + type="RFC", + number="804", + pages="1--12", + year=1981, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc804.txt", + key="RFC 804", + abstract={This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.}, + doi="10.17487/RFC0804", + } + +@misc{rfc805, + author="J. Postel", + title="{Computer mail meeting notes}", + howpublished="RFC 805", + series="Internet Request for Comments", + type="RFC", + number="805", + pages="1--6", + year=1982, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc805.txt", + key="RFC 805", + abstract={This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the ``username@hostname'' mailbox format to ``username(a)host.domain'', where the domain itself can be further strutured.}, + doi="10.17487/RFC0805", + } + +@misc{rfc806, + author="National Bureau of Standards", + title="{Proposed Federal Information Processing Standard: Specification for message format for computer based message systems}", + howpublished="RFC 806", + series="Internet Request for Comments", + type="RFC", + number="806", + pages="1--107", + year=1981, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 841", +url="https://www.rfc-editor.org/rfc/rfc806.txt", + key="RFC 806", + abstract={This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841.}, + doi="10.17487/RFC0806", + } + +@misc{rfc807, + author="J. Postel", + title="{Multimedia mail meeting notes}", + howpublished="RFC 807", + series="Internet Request for Comments", + type="RFC", + number="807", + pages="1--6", + year=1982, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc807.txt", + key="RFC 807", + abstract={This RFC consists of notes from a meeting held at USC Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments.}, + doi="10.17487/RFC0807", + } + +@misc{rfc808, + author="J. Postel", + title="{Summary of computer mail services meeting held at BBN on 10 January 1979}", + howpublished="RFC 808", + series="Internet Request for Comments", + type="RFC", + number="808", + pages="1--8", + year=1982, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc808.txt", + key="RFC 808", + abstract={This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided.}, + doi="10.17487/RFC0808", + } + +@misc{rfc809, + author="T. Chang", + title="{UCL facsimile system}", + howpublished="RFC 809", + series="Internet Request for Comments", + type="RFC", + number="809", + pages="1--99", + year=1982, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc809.txt", + key="RFC 809", + abstract={This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work are reported. Then the disciplines for system design are discussed. Finally, the implementation of the system are described, while detailed description are given as appendices.}, + doi="10.17487/RFC0809", + } + +@misc{rfc810, + author="E.J. Feinler and K. Harrenstien and Z. Su and V. White", + title="{DoD Internet host table specification}", + howpublished="RFC 810", + series="Internet Request for Comments", + type="RFC", + number="810", + pages="1--8", + year=1982, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 952", +url="https://www.rfc-editor.org/rfc/rfc810.txt", + key="RFC 810", + abstract={This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.}, + doi="10.17487/RFC0810", + } + +@misc{rfc811, + author="K. Harrenstien and V. White and E.J. Feinler", + title="{Hostnames Server}", + howpublished="RFC 811", + series="Internet Request for Comments", + type="RFC", + number="811", + pages="1--4", + year=1982, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 953", +url="https://www.rfc-editor.org/rfc/rfc811.txt", + key="RFC 811", + abstract={This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment.}, + doi="10.17487/RFC0811", + } + +@misc{rfc812, + author="K. Harrenstien and V. White", + title="{NICNAME/WHOIS}", + howpublished="RFC 812", + series="Internet Request for Comments", + type="RFC", + number="812", + pages="1--2", + year=1982, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 954, 3912", +url="https://www.rfc-editor.org/rfc/rfc812.txt", + key="RFC 812", + abstract={This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.}, + doi="10.17487/RFC0812", + } + +@misc{rfc813, + author="D.D. Clark", + title="{Window and Acknowledgement Strategy in TCP}", + howpublished="RFC 813 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="813", + pages="1--21", + year=1982, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc813.txt", + key="RFC 813", + abstract={This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.}, + doi="10.17487/RFC0813", + } + +@misc{rfc814, + author="D.D. Clark", + title="{Name, addresses, ports, and routes}", + howpublished="RFC 814 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="814", + pages="1--13", + year=1982, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc814.txt", + key="RFC 814", + abstract={This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.}, + doi="10.17487/RFC0814", + } + +@misc{rfc815, + author="D.D. Clark", + title="{IP datagram reassembly algorithms}", + howpublished="RFC 815", + series="Internet Request for Comments", + type="RFC", + number="815", + pages="1--8", + year=1982, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc815.txt", + key="RFC 815", + abstract={This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system.}, + doi="10.17487/RFC0815", + } + +@misc{rfc816, + author="D.D. Clark", + title="{Fault isolation and recovery}", + howpublished="RFC 816 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="816", + pages="1--11", + year=1982, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc816.txt", + key="RFC 816", + abstract={This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.}, + doi="10.17487/RFC0816", + } + +@misc{rfc817, + author="D.D. Clark", + title="{Modularity and efficiency in protocol implementation}", + howpublished="RFC 817 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="817", + pages="1--25", + year=1982, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc817.txt", + key="RFC 817", + abstract={This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.}, + doi="10.17487/RFC0817", + } + +@misc{rfc818, + author="J. Postel", + title="{Remote User Telnet service}", + howpublished="RFC 818 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="818", + pages="1--2", + year=1982, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc818.txt", + key="RFC 818", + abstract={This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.}, + keywords="RTELNET", + doi="10.17487/RFC0818", + } + +@misc{rfc819, + author="Z. Su and J. Postel", + title="{The Domain Naming Convention for Internet User Applications}", + howpublished="RFC 819", + series="Internet Request for Comments", + type="RFC", + number="819", + pages="1--18", + year=1982, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc819.txt", + key="RFC 819", + abstract={This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.}, + doi="10.17487/RFC0819", + } + +@misc{rfc820, + author="J. Postel", + title="{Assigned numbers}", + howpublished="RFC 820 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="820", + pages="1--22", + year=1982, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 870", +url="https://www.rfc-editor.org/rfc/rfc820.txt", + key="RFC 820", + abstract={This RFC is an old version, see RFC 870.}, + doi="10.17487/RFC0820", + } + +@misc{rfc821, + author="J. Postel", + title="{Simple Mail Transfer Protocol}", + howpublished="RFC 821 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="821", + pages="1--72", + year=1982, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2821", +url="https://www.rfc-editor.org/rfc/rfc821.txt", + key="RFC 821", + abstract={The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772.}, + keywords="SMTP", + doi="10.17487/RFC0821", + } + +@misc{rfc822, + author="D. Crocker", + title="{STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES}", + howpublished="RFC 822 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="822", + pages="1--49", + year=1982, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2822, updated by RFCs 1123, 2156, 1327, 1138, 1148", +url="https://www.rfc-editor.org/rfc/rfc822.txt", + key="RFC 822", + abstract={This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.}, + keywords="MAIL", + doi="10.17487/RFC0822", + } + +@misc{rfc823, + author="R.M. Hinden and A. Sheltzer", + title="{DARPA Internet gateway}", + howpublished="RFC 823 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="823", + pages="1--45", + year=1982, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc823.txt", + key="RFC 823", + abstract={This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.}, + keywords="GGP", + doi="10.17487/RFC0823", + } + +@misc{rfc824, + author="W.I. MacGregor and D.C. Tappan", + title="{CRONUS Virtual Local Network}", + howpublished="RFC 824", + series="Internet Request for Comments", + type="RFC", + number="824", + pages="1--41", + year=1982, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc824.txt", + key="RFC 824", + abstract={The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard.}, + doi="10.17487/RFC0824", + } + +@misc{rfc825, + author="J. Postel", + title="{Request for comments on Requests For Comments}", + howpublished="RFC 825", + series="Internet Request for Comments", + type="RFC", + number="825", + pages="1--2", + year=1982, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1111, 1543, 2223", +url="https://www.rfc-editor.org/rfc/rfc825.txt", + key="RFC 825", + abstract={This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs.}, + doi="10.17487/RFC0825", + } + +@misc{rfc826, + author="D. Plummer", + title="{An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware}", + howpublished="RFC 826 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="826", + pages="1--10", + year=1982, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5227, 5494", +url="https://www.rfc-editor.org/rfc/rfc826.txt", + key="RFC 826", + abstract={The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard.}, + keywords="ARP", + doi="10.17487/RFC0826", + } + +@misc{rfc827, + author="E.C. Rosen", + title="{Exterior Gateway Protocol (EGP)}", + howpublished="RFC 827", + series="Internet Request for Comments", + type="RFC", + number="827", + pages="1--46", + year=1982, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 904", +url="https://www.rfc-editor.org/rfc/rfc827.txt", + key="RFC 827", + abstract={This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged.}, + doi="10.17487/RFC0827", + } + +@misc{rfc828, + author="K. Owen", + title="{Data communications: IFIP's international ``network'' of experts}", + howpublished="RFC 828", + series="Internet Request for Comments", + type="RFC", + number="828", + pages="1--11", + year=1982, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc828.txt", + key="RFC 828", + abstract={This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.}, + doi="10.17487/RFC0828", + } + +@misc{rfc829, + author="V.G. Cerf", + title="{Packet satellite technology reference sources}", + howpublished="RFC 829", + series="Internet Request for Comments", + type="RFC", + number="829", + pages="1--5", + year=1982, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc829.txt", + key="RFC 829", + abstract={This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.}, + doi="10.17487/RFC0829", + } + +@misc{rfc830, + author="Z. Su", + title="{Distributed system for Internet name service}", + howpublished="RFC 830", + series="Internet Request for Comments", + type="RFC", + number="830", + pages="1--18", + year=1982, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc830.txt", + key="RFC 830", + abstract={This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.}, + doi="10.17487/RFC0830", + } + +@misc{rfc831, + author="R.T. Braden", + title="{Backup access to the European side of SATNET}", + howpublished="RFC 831", + series="Internet Request for Comments", + type="RFC", + number="831", + pages="1--6", + year=1982, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc831.txt", + key="RFC 831", + abstract={The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time.}, + doi="10.17487/RFC0831", + } + +@misc{rfc832, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 832", + series="Internet Request for Comments", + type="RFC", + number="832", + pages="1--13", + year=1982, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 833", +url="https://www.rfc-editor.org/rfc/rfc832.txt", + key="RFC 832", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.}, + doi="10.17487/RFC0832", + } + +@misc{rfc833, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 833", + series="Internet Request for Comments", + type="RFC", + number="833", + pages="1--13", + year=1982, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 834", +url="https://www.rfc-editor.org/rfc/rfc833.txt", + key="RFC 833", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.}, + doi="10.17487/RFC0833", + } + +@misc{rfc834, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 834", + series="Internet Request for Comments", + type="RFC", + number="834", + pages="1--13", + year=1982, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 835", +url="https://www.rfc-editor.org/rfc/rfc834.txt", + key="RFC 834", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82.}, + doi="10.17487/RFC0834", + } + +@misc{rfc835, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 835", + series="Internet Request for Comments", + type="RFC", + number="835", + pages="1--13", + year=1982, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 836", +url="https://www.rfc-editor.org/rfc/rfc835.txt", + key="RFC 835", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83.}, + doi="10.17487/RFC0835", + } + +@misc{rfc836, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 836", + series="Internet Request for Comments", + type="RFC", + number="836", + pages="1--13", + year=1983, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 837", +url="https://www.rfc-editor.org/rfc/rfc836.txt", + key="RFC 836", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83.}, + doi="10.17487/RFC0836", + } + +@misc{rfc837, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 837", + series="Internet Request for Comments", + type="RFC", + number="837", + pages="1--13", + year=1983, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 838", +url="https://www.rfc-editor.org/rfc/rfc837.txt", + key="RFC 837", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83.}, + doi="10.17487/RFC0837", + } + +@misc{rfc838, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 838", + series="Internet Request for Comments", + type="RFC", + number="838", + pages="1--13", + year=1983, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 839", +url="https://www.rfc-editor.org/rfc/rfc838.txt", + key="RFC 838", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83.}, + doi="10.17487/RFC0838", + } + +@misc{rfc839, + author="D. Smallberg", + title="{Who talks TCP?}", + howpublished="RFC 839", + series="Internet Request for Comments", + type="RFC", + number="839", + pages="1--14", + year=1983, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 842", +url="https://www.rfc-editor.org/rfc/rfc839.txt", + key="RFC 839", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83.}, + doi="10.17487/RFC0839", + } + +@misc{rfc840, + author="J. Postel", + title="{Official protocols}", + howpublished="RFC 840 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="840", + pages="1--23", + year=1983, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 880", +url="https://www.rfc-editor.org/rfc/rfc840.txt", + key="RFC 840", + abstract={This RFC has been revised, see RFC 880.}, + doi="10.17487/RFC0840", + } + +@misc{rfc841, + author="National Bureau of Standards", + title="{Specification for message format for Computer Based Message Systems}", + howpublished="RFC 841", + series="Internet Request for Comments", + type="RFC", + number="841", + pages="1--117", + year=1983, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc841.txt", + key="RFC 841", + abstract={This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. Obsoletes RFC 806.}, + doi="10.17487/RFC0841", + } + +@misc{rfc842, + author="D. Smallberg", + title="{Who talks TCP? - survey of 1 February 83}", + howpublished="RFC 842", + series="Internet Request for Comments", + type="RFC", + number="842", + pages="1--12", + year=1983, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 843", +url="https://www.rfc-editor.org/rfc/rfc842.txt", + key="RFC 842", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.}, + doi="10.17487/RFC0842", + } + +@misc{rfc843, + author="D. Smallberg", + title="{Who talks TCP? - survey of 8 February 83}", + howpublished="RFC 843", + series="Internet Request for Comments", + type="RFC", + number="843", + pages="1--13", + year=1983, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 845, updated by RFC 844", +url="https://www.rfc-editor.org/rfc/rfc843.txt", + key="RFC 843", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.}, + doi="10.17487/RFC0843", + } + +@misc{rfc844, + author="R. Clements", + title="{Who talks ICMP, too? - Survey of 18 February 1983}", + howpublished="RFC 844", + series="Internet Request for Comments", + type="RFC", + number="844", + pages="1--5", + year=1983, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc844.txt", + key="RFC 844", + abstract={This survey determines how many hosts are able to respond to TELENET connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses. The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting TELNET connection. The tests were run on 18-Feb-83.}, + doi="10.17487/RFC0844", + } + +@misc{rfc845, + author="D. Smallberg", + title="{Who talks TCP? - survey of 15 February 1983}", + howpublished="RFC 845", + series="Internet Request for Comments", + type="RFC", + number="845", + pages="1--14", + year=1983, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 846", +url="https://www.rfc-editor.org/rfc/rfc845.txt", + key="RFC 845", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.}, + doi="10.17487/RFC0845", + } + +@misc{rfc846, + author="D. Smallberg", + title="{Who talks TCP? - survey of 22 February 1983}", + howpublished="RFC 846", + series="Internet Request for Comments", + type="RFC", + number="846", + pages="1--14", + year=1983, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 847", +url="https://www.rfc-editor.org/rfc/rfc846.txt", + key="RFC 846", + abstract={This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.}, + doi="10.17487/RFC0846", + } + +@misc{rfc847, + author="A. Westine and D. Smallberg and J. Postel", + title="{Summary of Smallberg surveys}", + howpublished="RFC 847", + series="Internet Request for Comments", + type="RFC", + number="847", + pages="1--2", + year=1983, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc847.txt", + key="RFC 847", + abstract={This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).}, + doi="10.17487/RFC0847", + } + +@misc{rfc848, + author="D. Smallberg", + title="{Who provides the ``little'' TCP services?}", + howpublished="RFC 848", + series="Internet Request for Comments", + type="RFC", + number="848", + pages="1--5", + year=1983, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc848.txt", + key="RFC 848", + abstract={This RFC lists those hosts which provide any of these ``little'' TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA.}, + doi="10.17487/RFC0848", + } + +@misc{rfc849, + author="M.R. Crispin", + title="{Suggestions for improved host table distribution}", + howpublished="RFC 849", + series="Internet Request for Comments", + type="RFC", + number="849", + pages="1--2", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc849.txt", + key="RFC 849", + abstract={This RFC actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.}, + doi="10.17487/RFC0849", + } + +@misc{rfc850, + author="M.R. Horton", + title="{Standard for interchange of USENET messages}", + howpublished="RFC 850", + series="Internet Request for Comments", + type="RFC", + number="850", + pages="1--17", + year=1983, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1036", +url="https://www.rfc-editor.org/rfc/rfc850.txt", + key="RFC 850", + abstract={This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.}, + doi="10.17487/RFC0850", + } + +@misc{rfc851, + author="A.G. Malis", + title="{ARPANET 1822L Host Access Protocol}", + howpublished="RFC 851", + series="Internet Request for Comments", + type="RFC", + number="851", + pages="1--47", + year=1983, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 878", +url="https://www.rfc-editor.org/rfc/rfc851.txt", + key="RFC 851", + abstract={This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802.}, + doi="10.17487/RFC0851", + } + +@misc{rfc852, + author="A.G. Malis", + title="{ARPANET short blocking feature}", + howpublished="RFC 852", + series="Internet Request for Comments", + type="RFC", + number="852", + pages="1--13", + year=1983, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc852.txt", + key="RFC 852", + abstract={This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.}, + doi="10.17487/RFC0852", + } + +@misc{rfc854, + author="J. Postel and J.K. Reynolds", + title="{Telnet Protocol Specification}", + howpublished="RFC 854 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="854", + pages="1--15", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5198", +url="https://www.rfc-editor.org/rfc/rfc854.txt", + key="RFC 854", + abstract={This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication (``linking'') and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639.}, + keywords="TELNET", + doi="10.17487/RFC0854", + } + +@misc{rfc855, + author="J. Postel and J.K. Reynolds", + title="{Telnet Option Specifications}", + howpublished="RFC 855 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="855", + pages="1--3", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc855.txt", + key="RFC 855", + abstract={This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.}, + keywords="TELNET", + doi="10.17487/RFC0855", + } + +@misc{rfc856, + author="J. Postel and J. Reynolds", + title="{Telnet Binary Transmission}", + howpublished="RFC 856 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="856", + pages="1--4", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc856.txt", + key="RFC 856", + abstract={This Telnet Option enables a binary data mode between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15389.}, + keywords="TOPT-BIN", + doi="10.17487/RFC0856", + } + +@misc{rfc857, + author="J. Postel and J. Reynolds", + title="{Telnet Echo Option}", + howpublished="RFC 857 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="857", + pages="1--5", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc857.txt", + key="RFC 857", + abstract={This Telnet Option enables remote echoing by the other Telnet module. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15390.}, + keywords="TOPT-ECHO", + doi="10.17487/RFC0857", + } + +@misc{rfc858, + author="J. Postel and J. Reynolds", + title="{Telnet Suppress Go Ahead Option}", + howpublished="RFC 858 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="858", + pages="1--2", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc858.txt", + key="RFC 858", + abstract={This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15392.}, + keywords="TOPT-SUPP", + doi="10.17487/RFC0858", + } + +@misc{rfc859, + author="J. Postel and J. Reynolds", + title="{Telnet Status Option}", + howpublished="RFC 859 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="859", + pages="1--3", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc859.txt", + key="RFC 859", + abstract={This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).}, + keywords="TOPT-STAT", + doi="10.17487/RFC0859", + } + +@misc{rfc860, + author="J. Postel and J. Reynolds", + title="{Telnet Timing Mark Option}", + howpublished="RFC 860 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="860", + pages="1--4", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc860.txt", + key="RFC 860", + abstract={This Telnet Option provides a way to check the roundtrip path between two Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16238.}, + keywords="TOPT-TIM", + doi="10.17487/RFC0860", + } + +@misc{rfc861, + author="J. Postel and J. Reynolds", + title="{Telnet Extended Options: List Option}", + howpublished="RFC 861 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="861", + pages="1--2", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc861.txt", + key="RFC 861", + abstract={This Telnet Option provides a mechanism for extending the set of possible options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16239.}, + keywords="TOPT-EXTOP", + doi="10.17487/RFC0861", + } + +@misc{rfc862, + author="J. Postel", + title="{Echo Protocol}", + howpublished="RFC 862 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="862", + pages="1--1", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc862.txt", + key="RFC 862", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard. The Echo service simply sends back to the originating source any data it receives.}, + keywords="ECHO", + doi="10.17487/RFC0862", + } + +@misc{rfc863, + author="J. Postel", + title="{Discard Protocol}", + howpublished="RFC 863 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="863", + pages="1--1", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc863.txt", + key="RFC 863", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard. The Discard service simply throws away any data it receives.}, + keywords="DISCARD", + doi="10.17487/RFC0863", + } + +@misc{rfc864, + author="J. Postel", + title="{Character Generator Protocol}", + howpublished="RFC 864 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="864", + pages="1--3", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc864.txt", + key="RFC 864", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input.}, + keywords="CHARGEN", + doi="10.17487/RFC0864", + } + +@misc{rfc865, + author="J. Postel", + title="{Quote of the Day Protocol}", + howpublished="RFC 865 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="865", + pages="1--1", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc865.txt", + key="RFC 865", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input.}, + keywords="QUOTE", + doi="10.17487/RFC0865", + } + +@misc{rfc866, + author="J. Postel", + title="{Active users}", + howpublished="RFC 866 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="866", + pages="1--1", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc866.txt", + key="RFC 866", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard. The Active Users service simply sends a list of the currently active users on the host without regard to the input.}, + keywords="USERS", + doi="10.17487/RFC0866", + } + +@misc{rfc867, + author="J. Postel", + title="{Daytime Protocol}", + howpublished="RFC 867 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="867", + pages="1--2", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc867.txt", + key="RFC 867", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard. The Daytime service simply sends the current date and time as a character string without regard to the input.}, + keywords="DAYTIME", + doi="10.17487/RFC0867", + } + +@misc{rfc868, + author="J. Postel and K. Harrenstien", + title="{Time Protocol}", + howpublished="RFC 868 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="868", + pages="1--2", + year=1983, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc868.txt", + key="RFC 868", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900.}, + keywords="TIME", + doi="10.17487/RFC0868", + } + +@misc{rfc869, + author="R. Hinden", + title="{Host Monitoring Protocol}", + howpublished="RFC 869 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="869", + pages="1--72", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc869.txt", + key="RFC 869", + abstract={This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.}, + keywords="HMP, HMP", + doi="10.17487/RFC0869", + } + +@misc{rfc870, + author="J.K. Reynolds and J. Postel", + title="{Assigned numbers}", + howpublished="RFC 870 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="870", + pages="1--26", + year=1983, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 900", +url="https://www.rfc-editor.org/rfc/rfc870.txt", + key="RFC 870", + abstract={This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.}, + doi="10.17487/RFC0870", + } + +@misc{rfc871, + author="M.A. Padlipsky", + title="{Perspective on the ARPANET reference model}", + howpublished="RFC 871", + series="Internet Request for Comments", + type="RFC", + number="871", + pages="1--29", + year=1982, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc871.txt", + key="RFC 871", + abstract={This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.}, + doi="10.17487/RFC0871", + } + +@misc{rfc872, + author="M.A. Padlipsky", + title="{TCP-on-a-LAN}", + howpublished="RFC 872 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="872", + pages="1--10", + year=1982, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc872.txt", + key="RFC 872", + abstract={This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.}, + keywords="TCP LAN", + doi="10.17487/RFC0872", + } + +@misc{rfc873, + author="M.A. Padlipsky", + title="{Illusion of vendor support}", + howpublished="RFC 873", + series="Internet Request for Comments", + type="RFC", + number="873", + pages="1--12", + year=1982, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc873.txt", + key="RFC 873", + abstract={This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.}, + doi="10.17487/RFC0873", + } + +@misc{rfc874, + author="M.A. Padlipsky", + title="{Critique of X.25}", + howpublished="RFC 874", + series="Internet Request for Comments", + type="RFC", + number="874", + pages="1--17", + year=1982, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc874.txt", + key="RFC 874", + abstract={This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects. The memo also touches on security, and implementation issues. Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts.}, + doi="10.17487/RFC0874", + } + +@misc{rfc875, + author="M.A. Padlipsky", + title="{Gateways, architectures, and heffalumps}", + howpublished="RFC 875", + series="Internet Request for Comments", + type="RFC", + number="875", + pages="1--10", + year=1982, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc875.txt", + key="RFC 875", + abstract={This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing ``singularity points'', flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.}, + doi="10.17487/RFC0875", + } + +@misc{rfc876, + author="D. Smallberg", + title="{Survey of SMTP implementations}", + howpublished="RFC 876", + series="Internet Request for Comments", + type="RFC", + number="876", + pages="1--13", + year=1983, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc876.txt", + key="RFC 876", + abstract={This RFC is a survey of implementation status. It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol. It is expected that the status of the hosts reported on will change. This information must be treated as a snapshot of the state of these implemetations.}, + doi="10.17487/RFC0876", + } + +@misc{rfc877, + author="J.T. Korb", + title="{Standard for the transmission of IP datagrams over public data networks}", + howpublished="RFC 877", + series="Internet Request for Comments", + type="RFC", + number="877", + pages="1--2", + year=1983, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1356", +url="https://www.rfc-editor.org/rfc/rfc877.txt", + key="RFC 877", + abstract={This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.}, + doi="10.17487/RFC0877", + } + +@misc{rfc878, + author="A.G. Malis", + title="{ARPANET 1822L Host Access Protocol}", + howpublished="RFC 878", + series="Internet Request for Comments", + type="RFC", + number="878", + pages="1--51", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc878.txt", + key="RFC 878", + abstract={This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.}, + doi="10.17487/RFC0878", + } + +@misc{rfc879, + author="J. Postel", + title="{The TCP Maximum Segment Size and Related Topics}", + howpublished="RFC 879 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="879", + pages="1--11", + year=1983, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805, updated by RFC 6691", +url="https://www.rfc-editor.org/rfc/rfc879.txt", + key="RFC 879", + abstract={This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as ``advice to implementers''.}, + doi="10.17487/RFC0879", + } + +@misc{rfc880, + author="J.K. Reynolds and J. Postel", + title="{Official protocols}", + howpublished="RFC 880 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="880", + pages="1--26", + year=1983, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 901", +url="https://www.rfc-editor.org/rfc/rfc880.txt", + key="RFC 880", + abstract={This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840.}, + doi="10.17487/RFC0880", + } + +@misc{rfc881, + author="J. Postel", + title="{Domain names plan and schedule}", + howpublished="RFC 881", + series="Internet Request for Comments", + type="RFC", + number="881", + pages="1--10", + year=1983, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 897", +url="https://www.rfc-editor.org/rfc/rfc881.txt", + key="RFC 881", + abstract={This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.}, + doi="10.17487/RFC0881", + } + +@misc{rfc882, + author="P.V. Mockapetris", + title="{Domain names: Concepts and facilities}", + howpublished="RFC 882", + series="Internet Request for Comments", + type="RFC", + number="882", + pages="1--31", + year=1983, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1034, 1035, updated by RFC 973", +url="https://www.rfc-editor.org/rfc/rfc882.txt", + key="RFC 882", + abstract={This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.}, + doi="10.17487/RFC0882", + } + +@misc{rfc883, + author="P.V. Mockapetris", + title="{Domain names: Implementation specification}", + howpublished="RFC 883", + series="Internet Request for Comments", + type="RFC", + number="883", + pages="1--74", + year=1983, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1034, 1035, updated by RFC 973", +url="https://www.rfc-editor.org/rfc/rfc883.txt", + key="RFC 883", + abstract={This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.}, + doi="10.17487/RFC0883", + } + +@misc{rfc884, + author="M. Solomon and E. Wimmers", + title="{Telnet terminal type option}", + howpublished="RFC 884", + series="Internet Request for Comments", + type="RFC", + number="884", + pages="1--5", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 930", +url="https://www.rfc-editor.org/rfc/rfc884.txt", + key="RFC 884", + abstract={This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.}, + doi="10.17487/RFC0884", + } + +@misc{rfc885, + author="J. Postel", + title="{Telnet end of record option}", + howpublished="RFC 885 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="885", + pages="1--2", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc885.txt", + key="RFC 885", + abstract={This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.}, + keywords="TOPT-EOR", + doi="10.17487/RFC0885", + } + +@misc{rfc886, + author="M.T. Rose", + title="{Proposed standard for message header munging}", + howpublished="RFC 886", + series="Internet Request for Comments", + type="RFC", + number="886", + pages="1--16", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc886.txt", + key="RFC 886", + abstract={This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified.}, + doi="10.17487/RFC0886", + } + +@misc{rfc887, + author="M. Accetta", + title="{Resource Location Protocol}", + howpublished="RFC 887 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="887", + pages="1--16", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc887.txt", + key="RFC 887", + abstract={This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.}, + keywords="RLP", + doi="10.17487/RFC0887", + } + +@misc{rfc888, + author="L. Seamonson and E.C. Rosen", + title="{``STUB'' Exterior Gateway Protocol}", + howpublished="RFC 888", + series="Internet Request for Comments", + type="RFC", + number="888", + pages="1--39", + year=1984, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 904", +url="https://www.rfc-editor.org/rfc/rfc888.txt", + key="RFC 888", + abstract={This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document.}, + doi="10.17487/RFC0888", + } + +@misc{rfc889, + author="D.L. Mills", + title="{Internet Delay Experiments}", + howpublished="RFC 889 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="889", + pages="1--12", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc889.txt", + key="RFC 889", + abstract={This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers.}, + doi="10.17487/RFC0889", + } + +@misc{rfc890, + author="J. Postel", + title="{Exterior Gateway Protocol implementation schedule}", + howpublished="RFC 890", + series="Internet Request for Comments", + type="RFC", + number="890", + pages="1--3", + year=1984, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc890.txt", + key="RFC 890", + abstract={This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol.}, + keywords="EGP", + doi="10.17487/RFC0890", + } + +@misc{rfc891, + author="D.L. Mills", + title="{DCN Local-Network Protocols}", + howpublished="RFC 891 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="891", + pages="1--26", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc891.txt", + key="RFC 891", + abstract={This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks.}, + keywords="IP-DC", + doi="10.17487/RFC0891", + } + +@misc{rfc892, + author="International Organization for Standardization", + title="{ISO Transport Protocol specification}", + howpublished="RFC 892", + series="Internet Request for Comments", + type="RFC", + number="892", + pages="1--82", + year=1983, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 905", +url="https://www.rfc-editor.org/rfc/rfc892.txt", + key="RFC 892", + abstract={This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date.}, + doi="10.17487/RFC0892", + } + +@misc{rfc893, + author="S. Leffler and M.J. Karels", + title="{Trailer encapsulations}", + howpublished="RFC 893", + series="Internet Request for Comments", + type="RFC", + number="893", + pages="1--6", + year=1984, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc893.txt", + key="RFC 893", + abstract={This RFC discusses the motivation for use of ``trailer encapsulations'' on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA Internet community.}, + doi="10.17487/RFC0893", + } + +@misc{rfc894, + author="C. Hornig", + title="{A Standard for the Transmission of IP Datagrams over Ethernet Networks}", + howpublished="RFC 894 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="894", + pages="1--3", + year=1984, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc894.txt", + key="RFC 894", + abstract={This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community.}, + keywords="IP-E", + doi="10.17487/RFC0894", + } + +@misc{rfc895, + author="J. Postel", + title="{Standard for the transmission of IP datagrams over experimental Ethernet networks}", + howpublished="RFC 895 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="895", + pages="1--3", + year=1984, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc895.txt", + key="RFC 895", + abstract={This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA Internet community.}, + keywords="IP-EE", + doi="10.17487/RFC0895", + } + +@misc{rfc896, + author="J. Nagle", + title="{Congestion Control in IP/TCP Internetworks}", + howpublished="RFC 896 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="896", + pages="1--9", + year=1984, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc896.txt", + key="RFC 896", + abstract={This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.}, + doi="10.17487/RFC0896", + } + +@misc{rfc897, + author="J. Postel", + title="{Domain name system implementation schedule}", + howpublished="RFC 897", + series="Internet Request for Comments", + type="RFC", + number="897", + pages="1--8", + year=1984, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 921", +url="https://www.rfc-editor.org/rfc/rfc897.txt", + key="RFC 897", + abstract={This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA.}, + doi="10.17487/RFC0897", + } + +@misc{rfc898, + author="R.M. Hinden and J. Postel and M. Muuss and J.K. Reynolds", + title="{Gateway special interest group meeting notes}", + howpublished="RFC 898", + series="Internet Request for Comments", + type="RFC", + number="898", + pages="1--24", + year=1984, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc898.txt", + key="RFC 898", + abstract={This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note.}, + doi="10.17487/RFC0898", + } + +@misc{rfc899, + author="J. Postel and A. Westine", + title="{Request For Comments summary notes: 800-899}", + howpublished="RFC 899 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="899", + pages="1--18", + year=1984, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc899.txt", + key="RFC 899", + doi="10.17487/RFC0899", + } + +@misc{rfc900, + author="J.K. Reynolds and J. Postel", + title="{Assigned Numbers}", + howpublished="RFC 900 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="900", + pages="1--43", + year=1984, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 923", +url="https://www.rfc-editor.org/rfc/rfc900.txt", + key="RFC 900", + abstract={This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.}, + doi="10.17487/RFC0900", + } + +@misc{rfc901, + author="J.K. Reynolds and J. Postel", + title="{Official ARPA-Internet protocols}", + howpublished="RFC 901", + series="Internet Request for Comments", + type="RFC", + number="901", + pages="1--28", + year=1984, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 924", +url="https://www.rfc-editor.org/rfc/rfc901.txt", + key="RFC 901", + abstract={This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991.}, + doi="10.17487/RFC0901", + } + +@misc{rfc902, + author="J.K. Reynolds and J. Postel", + title="{ARPA Internet Protocol policy}", + howpublished="RFC 902", + series="Internet Request for Comments", + type="RFC", + number="902", + pages="1--5", + year=1984, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc902.txt", + key="RFC 902", + abstract={The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA.}, + doi="10.17487/RFC0902", + } + +@misc{rfc903, + author="R. Finlayson and T. Mann and J.C. Mogul and M. Theimer", + title="{A Reverse Address Resolution Protocol}", + howpublished="RFC 903 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="903", + pages="1--4", + year=1984, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc903.txt", + key="RFC 903", + abstract={This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.}, + keywords="RARP", + doi="10.17487/RFC0903", + } + +@misc{rfc904, + author="D.L. Mills", + title="{Exterior Gateway Protocol formal specification}", + howpublished="RFC 904 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="904", + pages="1--30", + year=1984, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc904.txt", + key="RFC 904", + abstract={RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.}, + keywords="EGP", + doi="10.17487/RFC0904", + } + +@misc{rfc905, + author="ISO", + title="{ISO Transport Protocol specification ISO DP 8073}", + howpublished="RFC 905", + series="Internet Request for Comments", + type="RFC", + number="905", + pages="1--164", + year=1984, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc905.txt", + key="RFC 905", + abstract={This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters.}, + doi="10.17487/RFC0905", + } + +@misc{rfc906, + author="R. Finlayson", + title="{Bootstrap loading using TFTP}", + howpublished="RFC 906", + series="Internet Request for Comments", + type="RFC", + number="906", + pages="1--4", + year=1984, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc906.txt", + key="RFC 906", + abstract={It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case.}, + doi="10.17487/RFC0906", + } + +@misc{rfc907, + author="Bolt Beranek and Newman Laboratories", + title="{Host Access Protocol specification}", + howpublished="RFC 907 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="907", + pages="1--75", + year=1984, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1221", +url="https://www.rfc-editor.org/rfc/rfc907.txt", + key="RFC 907", + abstract={This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel.}, + keywords="IP-WB", + doi="10.17487/RFC0907", + } + +@misc{rfc908, + author="D. Velten and R.M. Hinden and J. Sax", + title="{Reliable Data Protocol}", + howpublished="RFC 908 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="908", + pages="1--62", + year=1984, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1151", +url="https://www.rfc-editor.org/rfc/rfc908.txt", + key="RFC 908", + abstract={The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.}, + keywords="RDP", + doi="10.17487/RFC0908", + } + +@misc{rfc909, + author="C. Welles and W. Milliken", + title="{Loader Debugger Protocol}", + howpublished="RFC 909 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="909", + pages="1--135", + year=1984, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc909.txt", + key="RFC 909", + abstract={The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.}, + keywords="LDP", + doi="10.17487/RFC0909", + } + +@misc{rfc910, + author="H.C. Forsdick", + title="{Multimedia mail meeting notes}", + howpublished="RFC 910", + series="Internet Request for Comments", + type="RFC", + number="910", + pages="1--11", + year=1984, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc910.txt", + key="RFC 910", + abstract={This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit.}, + doi="10.17487/RFC0910", + } + +@misc{rfc911, + author="P. Kirton", + title="{EGP Gateway under Berkeley UNIX 4.2}", + howpublished="RFC 911", + series="Internet Request for Comments", + type="RFC", + number="911", + pages="1--23", + year=1984, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc911.txt", + key="RFC 911", + abstract={This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion).}, + doi="10.17487/RFC0911", + } + +@misc{rfc912, + author="M. St. Johns", + title="{Authentication service}", + howpublished="RFC 912", + series="Internet Request for Comments", + type="RFC", + number="912", + pages="1--3", + year=1984, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 931", +url="https://www.rfc-editor.org/rfc/rfc912.txt", + key="RFC 912", + abstract={This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.}, + doi="10.17487/RFC0912", + } + +@misc{rfc913, + author="M. Lottor", + title="{Simple File Transfer Protocol}", + howpublished="RFC 913 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="913", + pages="1--15", + year=1984, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc913.txt", + key="RFC 913", + abstract={This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.}, + keywords="SFTP, FTP", + doi="10.17487/RFC0913", + } + +@misc{rfc914, + author="D.J. Farber and G. Delp and T.M. Conte", + title="{Thinwire protocol for connecting personal computers to the Internet}", + howpublished="RFC 914 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="914", + pages="1--22", + year=1984, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc914.txt", + key="RFC 914", + abstract={This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.}, + keywords="THINWIRE", + doi="10.17487/RFC0914", + } + +@misc{rfc915, + author="M.A. Elvy and R. Nedved", + title="{Network mail path service}", + howpublished="RFC 915", + series="Internet Request for Comments", + type="RFC", + number="915", + pages="1--11", + year=1984, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc915.txt", + key="RFC 915", + abstract={This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server.}, + doi="10.17487/RFC0915", + } + +@misc{rfc916, + author="G.G. Finn", + title="{Reliable Asynchronous Transfer Protocol (RATP)}", + howpublished="RFC 916 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="916", + pages="1--54", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc916.txt", + key="RFC 916", + abstract={This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.}, + keywords="RATP", + doi="10.17487/RFC0916", + } + +@misc{rfc917, + author="J.C. Mogul", + title="{Internet subnets}", + howpublished="RFC 917", + series="Internet Request for Comments", + type="RFC", + number="917", + pages="1--22", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc917.txt", + key="RFC 917", + abstract={This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0917", + } + +@misc{rfc918, + author="J.K. Reynolds", + title="{Post Office Protocol}", + howpublished="RFC 918", + series="Internet Request for Comments", + type="RFC", + number="918", + pages="1--5", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 937", +url="https://www.rfc-editor.org/rfc/rfc918.txt", + key="RFC 918", + abstract={This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP.}, + doi="10.17487/RFC0918", + } + +@misc{rfc919, + author="J.C. Mogul", + title="{Broadcasting Internet Datagrams}", + howpublished="RFC 919 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="919", + pages="1--8", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc919.txt", + key="RFC 919", + abstract={This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC0919", + } + +@misc{rfc920, + author="J. Postel and J.K. Reynolds", + title="{Domain requirements}", + howpublished="RFC 920", + series="Internet Request for Comments", + type="RFC", + number="920", + pages="1--14", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc920.txt", + key="RFC 920", + abstract={This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA.}, + doi="10.17487/RFC0920", + } + +@misc{rfc921, + author="J. Postel", + title="{Domain name system implementation schedule - revised}", + howpublished="RFC 921", + series="Internet Request for Comments", + type="RFC", + number="921", + pages="1--13", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc921.txt", + key="RFC 921", + abstract={This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references.}, + doi="10.17487/RFC0921", + } + +@misc{rfc922, + author="J.C. Mogul", + title="{Broadcasting Internet datagrams in the presence of subnets}", + howpublished="RFC 922 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="922", + pages="1--12", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc922.txt", + key="RFC 922", + abstract={We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC0922", + } + +@misc{rfc923, + author="J.K. Reynolds and J. Postel", + title="{Assigned numbers}", + howpublished="RFC 923 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="923", + pages="1--47", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 943", +url="https://www.rfc-editor.org/rfc/rfc923.txt", + key="RFC 923", + abstract={This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.}, + doi="10.17487/RFC0923", + } + +@misc{rfc924, + author="J.K. Reynolds and J. Postel", + title="{Official ARPA-Internet protocols for connecting personal computers to the Internet}", + howpublished="RFC 924", + series="Internet Request for Comments", + type="RFC", + number="924", + pages="1--35", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 944", +url="https://www.rfc-editor.org/rfc/rfc924.txt", + key="RFC 924", + abstract={This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.}, + doi="10.17487/RFC0924", + } + +@misc{rfc925, + author="J. Postel", + title="{Multi-LAN address resolution}", + howpublished="RFC 925", + series="Internet Request for Comments", + type="RFC", + number="925", + pages="1--15", + year=1984, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc925.txt", + key="RFC 925", + abstract={The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of ``explicit subnets'' in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of ``transparent subnets'' supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0925", + } + +@misc{rfc926, + author="International Organization for Standardization", + title="{Protocol for providing the connectionless mode network services}", + howpublished="RFC 926", + series="Internet Request for Comments", + type="RFC", + number="926", + pages="1--107", + year=1984, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 994", +url="https://www.rfc-editor.org/rfc/rfc926.txt", + key="RFC 926", + abstract={This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet.}, + doi="10.17487/RFC0926", + } + +@misc{rfc927, + author="B.A. Anderson", + title="{TACACS user identification Telnet option}", + howpublished="RFC 927 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="927", + pages="1--4", + year=1984, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc927.txt", + key="RFC 927", + abstract={The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="TOPT-TACACS", + doi="10.17487/RFC0927", + } + +@misc{rfc928, + author="M.A. Padlipsky", + title="{Introduction to proposed DoD standard H-FP}", + howpublished="RFC 928", + series="Internet Request for Comments", + type="RFC", + number="928", + pages="1--21", + year=1984, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc928.txt", + key="RFC 928", + abstract={The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of ``standard''. Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0928", + } + +@misc{rfc929, + author="J. Lilienkamp and R. Mandell and M.A. Padlipsky", + title="{Proposed Host-Front End Protocol}", + howpublished="RFC 929 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="929", + pages="1--56", + year=1984, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc929.txt", + key="RFC 929", + abstract={The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="HFEP", + doi="10.17487/RFC0929", + } + +@misc{rfc930, + author="M. Solomon and E. Wimmers", + title="{Telnet terminal type option}", + howpublished="RFC 930", + series="Internet Request for Comments", + type="RFC", + number="930", + pages="1--4", + year=1985, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1091", +url="https://www.rfc-editor.org/rfc/rfc930.txt", + key="RFC 930", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.}, + doi="10.17487/RFC0930", + } + +@misc{rfc931, + author="M. St. Johns", + title="{Authentication server}", + howpublished="RFC 931", + series="Internet Request for Comments", + type="RFC", + number="931", + pages="1--5", + year=1985, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1413", +url="https://www.rfc-editor.org/rfc/rfc931.txt", + key="RFC 931", + abstract={This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.}, + doi="10.17487/RFC0931", + } + +@misc{rfc932, + author="D.D. Clark", + title="{Subnetwork addressing scheme}", + howpublished="RFC 932", + series="Internet Request for Comments", + type="RFC", + number="932", + pages="1--4", + year=1985, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc932.txt", + key="RFC 932", + abstract={This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways.}, + doi="10.17487/RFC0932", + } + +@misc{rfc933, + author="S. Silverman", + title="{Output marking Telnet option}", + howpublished="RFC 933 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="933", + pages="1--4", + year=1985, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc933.txt", + key="RFC 933", + abstract={This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.}, + keywords="TOPT-OM", + doi="10.17487/RFC0933", + } + +@misc{rfc934, + author="M.T. Rose and E.A. Stefferud", + title="{Proposed standard for message encapsulation}", + howpublished="RFC 934", + series="Internet Request for Comments", + type="RFC", + number="934", + pages="1--10", + year=1985, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc934.txt", + key="RFC 934", + abstract={This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms ``bursting''), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0934", + } + +@misc{rfc935, + author="J.G. Robinson", + title="{Reliable link layer protocols}", + howpublished="RFC 935", + series="Internet Request for Comments", + type="RFC", + number="935", + pages="1--12", + year=1985, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc935.txt", + key="RFC 935", + abstract={This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0935", + } + +@misc{rfc936, + author="M.J. Karels", + title="{Another Internet subnet addressing scheme}", + howpublished="RFC 936", + series="Internet Request for Comments", + type="RFC", + number="936", + pages="1--4", + year=1985, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc936.txt", + key="RFC 936", + abstract={There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a propo sed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0936", + } + +@misc{rfc937, + author="M. Butler and J. Postel and D. Chase and J. Goldberger and J.K. Reynolds", + title="{Post Office Protocol: Version 2}", + howpublished="RFC 937 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="937", + pages="1--24", + year=1985, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc937.txt", + key="RFC 937", + abstract={This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918.}, + keywords="POP2, Post Office Protocol, Version 2", + doi="10.17487/RFC0937", + } + +@misc{rfc938, + author="T. Miller", + title="{Internet Reliable Transaction Protocol functional and interface specification}", + howpublished="RFC 938 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="938", + pages="1--19", + year=1985, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc938.txt", + key="RFC 938", + abstract={This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="IRTP", + doi="10.17487/RFC0938", + } + +@misc{rfc939, + author="National Research Council", + title="{Executive summary of the NRC report on transport protocols for Department of Defense data networks}", + howpublished="RFC 939", + series="Internet Request for Comments", + type="RFC", + number="939", + pages="1--20", + year=1985, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc939.txt", + key="RFC 939", + abstract={This RFC reproduces the material from the ``front pages'' of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community.}, + doi="10.17487/RFC0939", + } + +@misc{rfc940, + author="Gateway Algorithms and Data Structures Task Force", + title="{Toward an Internet standard scheme for subnetting}", + howpublished="RFC 940", + series="Internet Request for Comments", + type="RFC", + number="940", + pages="1--3", + year=1985, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc940.txt", + key="RFC 940", + abstract={Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet.}, + doi="10.17487/RFC0940", + } + +@misc{rfc941, + author="International Organization for Standardization", + title="{Addendum to the network service definition covering network layer addressing}", + howpublished="RFC 941", + series="Internet Request for Comments", + type="RFC", + number="941", + pages="1--34", + year=1985, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc941.txt", + key="RFC 941", + abstract={This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.}, + doi="10.17487/RFC0941", + } + +@misc{rfc942, + author="National Research Council", + title="{Transport protocols for Department of Defense data networks}", + howpublished="RFC 942", + series="Internet Request for Comments", + type="RFC", + number="942", + pages="1--88", + year=1985, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc942.txt", + key="RFC 942", + abstract={This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).}, + doi="10.17487/RFC0942", + } + +@misc{rfc943, + author="J.K. Reynolds and J. Postel", + title="{Assigned numbers}", + howpublished="RFC 943 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="943", + pages="1--50", + year=1985, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 960", +url="https://www.rfc-editor.org/rfc/rfc943.txt", + key="RFC 943", + abstract={This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.}, + doi="10.17487/RFC0943", + } + +@misc{rfc944, + author="J.K. Reynolds and J. Postel", + title="{Official ARPA-Internet protocols}", + howpublished="RFC 944", + series="Internet Request for Comments", + type="RFC", + number="944", + pages="1--40", + year=1985, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 961", +url="https://www.rfc-editor.org/rfc/rfc944.txt", + key="RFC 944", + abstract={This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.}, + doi="10.17487/RFC0944", + } + +@misc{rfc945, + author="J. Postel", + title="{DoD statement on the NRC report}", + howpublished="RFC 945", + series="Internet Request for Comments", + type="RFC", + number="945", + pages="1--2", + year=1985, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1039", +url="https://www.rfc-editor.org/rfc/rfc945.txt", + key="RFC 945", + abstract={In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only.}, + doi="10.17487/RFC0945", + } + +@misc{rfc946, + author="R. Nedved", + title="{Telnet terminal location number option}", + howpublished="RFC 946 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="946", + pages="1--4", + year=1985, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc946.txt", + key="RFC 946", + abstract={Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="TOPT-TLN", + doi="10.17487/RFC0946", + } + +@misc{rfc947, + author="K. Lebowitz and D. Mankins", + title="{Multi-network broadcasting within the Internet}", + howpublished="RFC 947", + series="Internet Request for Comments", + type="RFC", + number="947", + pages="1--5", + year=1985, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc947.txt", + key="RFC 947", + abstract={This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater.}, + doi="10.17487/RFC0947", + } + +@misc{rfc948, + author="I. Winston", + title="{Two methods for the transmission of IP datagrams over IEEE 802.3 networks}", + howpublished="RFC 948", + series="Internet Request for Comments", + type="RFC", + number="948", + pages="1--7", + year=1985, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1042", +url="https://www.rfc-editor.org/rfc/rfc948.txt", + key="RFC 948", + abstract={This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0948", + } + +@misc{rfc949, + author="M.A. Padlipsky", + title="{FTP unique-named store command}", + howpublished="RFC 949", + series="Internet Request for Comments", + type="RFC", + number="949", + pages="1--2", + year=1985, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc949.txt", + key="RFC 949", + abstract={There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959.}, + doi="10.17487/RFC0949", + } + +@misc{rfc950, + author="J.C. Mogul and J. Postel", + title="{Internet Standard Subnetting Procedure}", + howpublished="RFC 950 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="950", + pages="1--18", + year=1985, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6918", +url="https://www.rfc-editor.org/rfc/rfc950.txt", + key="RFC 950", + abstract={This memo discusses the utility of ``subnets'' of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed.}, + keywords="Address", + doi="10.17487/RFC0950", + } + +@misc{rfc951, + author="W.J. Croft and J. Gilmore", + title="{Bootstrap Protocol}", + howpublished="RFC 951 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="951", + pages="1--12", + year=1985, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1395, 1497, 1532, 1542, 5494", +url="https://www.rfc-editor.org/rfc/rfc951.txt", + key="RFC 951", + abstract={This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="BOOTP", + doi="10.17487/RFC0951", + } + +@misc{rfc952, + author="K. Harrenstien and M.K. Stahl and E.J. Feinler", + title="{DoD Internet host table specification}", + howpublished="RFC 952", + series="Internet Request for Comments", + type="RFC", + number="952", + pages="1--6", + year=1985, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1123", +url="https://www.rfc-editor.org/rfc/rfc952.txt", + key="RFC 952", + abstract={This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date.}, + doi="10.17487/RFC0952", + } + +@misc{rfc953, + author="K. Harrenstien and M.K. Stahl and E.J. Feinler", + title="{Hostname Server}", + howpublished="RFC 953 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="953", + pages="1--5", + year=1985, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc953.txt", + key="RFC 953", + abstract={This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date.}, + keywords="HOSTNAME", + doi="10.17487/RFC0953", + } + +@misc{rfc954, + author="K. Harrenstien and M.K. Stahl and E.J. Feinler", + title="{NICNAME/WHOIS}", + howpublished="RFC 954 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="954", + pages="1--4", + year=1985, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3912", +url="https://www.rfc-editor.org/rfc/rfc954.txt", + key="RFC 954", + abstract={This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.}, + keywords="NICNAME", + doi="10.17487/RFC0954", + } + +@misc{rfc955, + author="R.T. Braden", + title="{Towards a transport service for transaction processing applications}", + howpublished="RFC 955", + series="Internet Request for Comments", + type="RFC", + number="955", + pages="1--10", + year=1985, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc955.txt", + key="RFC 955", + abstract={The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite ``far apart''. We want to examine an important class of applications, those which perform what is often called ``transaction processing''. We will see that the communication needs for these applications fall into the gap ``between'' TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protoco l proposal.}, + doi="10.17487/RFC0955", + } + +@misc{rfc956, + author="D.L. Mills", + title="{Algorithms for synchronizing network clocks}", + howpublished="RFC 956", + series="Internet Request for Comments", + type="RFC", + number="956", + pages="1--26", + year=1985, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc956.txt", + key="RFC 956", + abstract={This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms.}, + doi="10.17487/RFC0956", + } + +@misc{rfc957, + author="D.L. Mills", + title="{Experiments in network clock synchronization}", + howpublished="RFC 957", + series="Internet Request for Comments", + type="RFC", + number="957", + pages="1--27", + year=1985, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc957.txt", + key="RFC 957", + abstract={This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture.}, + doi="10.17487/RFC0957", + } + +@misc{rfc958, + author="D.L. Mills", + title="{Network Time Protocol (NTP)}", + howpublished="RFC 958", + series="Internet Request for Comments", + type="RFC", + number="958", + pages="1--14", + year=1985, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1059, 1119, 1305", +url="https://www.rfc-editor.org/rfc/rfc958.txt", + key="RFC 958", + abstract={This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="NTP, time, clock, synchronization", + doi="10.17487/RFC0958", + } + +@misc{rfc959, + author="J. Postel and J. Reynolds", + title="{File Transfer Protocol}", + howpublished="RFC 959 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="959", + pages="1--69", + year=1985, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2228, 2640, 2773, 3659, 5797, 7151", +url="https://www.rfc-editor.org/rfc/rfc959.txt", + key="RFC 959", + abstract={This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.}, + keywords="FTP", + doi="10.17487/RFC0959", + } + +@misc{rfc960, + author="J.K. Reynolds and J. Postel", + title="{Assigned numbers}", + howpublished="RFC 960 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="960", + pages="1--60", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 990", +url="https://www.rfc-editor.org/rfc/rfc960.txt", + key="RFC 960", + abstract={This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.}, + doi="10.17487/RFC0960", + } + +@misc{rfc961, + author="J.K. Reynolds and J. Postel", + title="{Official ARPA-Internet protocols}", + howpublished="RFC 961", + series="Internet Request for Comments", + type="RFC", + number="961", + pages="1--38", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 991", +url="https://www.rfc-editor.org/rfc/rfc961.txt", + key="RFC 961", + abstract={This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.}, + doi="10.17487/RFC0961", + } + +@misc{rfc962, + author="M.A. Padlipsky", + title="{TCP-4 prime}", + howpublished="RFC 962", + series="Internet Request for Comments", + type="RFC", + number="962", + pages="1--2", + year=1985, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc962.txt", + key="RFC 962", + abstract={This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard.}, + doi="10.17487/RFC0962", + } + +@misc{rfc963, + author="D.P. Sidhu", + title="{Some problems with the specification of the Military Standard Internet Protocol}", + howpublished="RFC 963", + series="Internet Request for Comments", + type="RFC", + number="963", + pages="1--19", + year=1985, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc963.txt", + key="RFC 963", + abstract={The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems.}, + doi="10.17487/RFC0963", + } + +@misc{rfc964, + author="D.P. Sidhu and T. Blumer", + title="{Some problems with the specification of the Military Standard Transmission Control Protocol}", + howpublished="RFC 964 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="964", + pages="1--10", + year=1985, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc964.txt", + key="RFC 964", + abstract={The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems.}, + doi="10.17487/RFC0964", + } + +@misc{rfc965, + author="L. Aguilar", + title="{Format for a graphical communication protocol}", + howpublished="RFC 965", + series="Internet Request for Comments", + type="RFC", + number="965", + pages="1--51", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc965.txt", + key="RFC 965", + abstract={This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions.}, + doi="10.17487/RFC0965", + } + +@misc{rfc966, + author="S.E. Deering and D.R. Cheriton", + title="{Host groups: A multicast extension to the Internet Protocol}", + howpublished="RFC 966", + series="Internet Request for Comments", + type="RFC", + number="966", + pages="1--27", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 988", +url="https://www.rfc-editor.org/rfc/rfc966.txt", + key="RFC 966", + abstract={This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988.}, + doi="10.17487/RFC0966", + } + +@misc{rfc967, + author="M.A. Padlipsky", + title="{All victims together}", + howpublished="RFC 967", + series="Internet Request for Comments", + type="RFC", + number="967", + pages="1--2", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc967.txt", + key="RFC 967", + abstract={This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged.}, + doi="10.17487/RFC0967", + } + +@misc{rfc968, + author="V.G. Cerf", + title="{Twas the night before start-up}", + howpublished="RFC 968", + series="Internet Request for Comments", + type="RFC", + number="968", + pages="1--2", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc968.txt", + key="RFC 968", + abstract={This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.}, + doi="10.17487/RFC0968", + } + +@misc{rfc969, + author="D.D. Clark and M.L. Lambert and L. Zhang", + title="{NETBLT: A bulk data transfer protocol}", + howpublished="RFC 969", + series="Internet Request for Comments", + type="RFC", + number="969", + pages="1--15", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 998", +url="https://www.rfc-editor.org/rfc/rfc969.txt", + key="RFC 969", + abstract={This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998.}, + doi="10.17487/RFC0969", + } + +@misc{rfc970, + author="J. Nagle", + title="{On Packet Switches With Infinite Storage}", + howpublished="RFC 970", + series="Internet Request for Comments", + type="RFC", + number="970", + pages="1--9", + year=1985, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc970.txt", + key="RFC 970", + abstract={The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time.}, + doi="10.17487/RFC0970", + } + +@misc{rfc971, + author="A.L. DeSchon", + title="{Survey of data representation standards}", + howpublished="RFC 971", + series="Internet Request for Comments", + type="RFC", + number="971", + pages="1--9", + year=1986, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc971.txt", + key="RFC 971", + abstract={This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard.}, + doi="10.17487/RFC0971", + } + +@misc{rfc972, + author="F.J. Wancho", + title="{Password Generator Protocol}", + howpublished="RFC 972", + series="Internet Request for Comments", + type="RFC", + number="972", + pages="1--2", + year=1986, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc972.txt", + key="RFC 972", + abstract={This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character ``words'' with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard.}, + doi="10.17487/RFC0972", + } + +@misc{rfc973, + author="P.V. Mockapetris", + title="{Domain system changes and observations}", + howpublished="RFC 973", + series="Internet Request for Comments", + type="RFC", + number="973", + pages="1--10", + year=1986, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1034, 1035", +url="https://www.rfc-editor.org/rfc/rfc973.txt", + key="RFC 973", + abstract={This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.}, + doi="10.17487/RFC0973", + } + +@misc{rfc974, + author="C. Partridge", + title="{Mail routing and the domain system}", + howpublished="RFC 974 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="974", + pages="1--7", + year=1986, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2821", +url="https://www.rfc-editor.org/rfc/rfc974.txt", + key="RFC 974", + abstract={This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.}, + keywords="DNS-MX", + doi="10.17487/RFC0974", + } + +@misc{rfc975, + author="D.L. Mills", + title="{Autonomous confederations}", + howpublished="RFC 975", + series="Internet Request for Comments", + type="RFC", + number="975", + pages="1--10", + year=1986, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc975.txt", + key="RFC 975", + abstract={This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested.}, + doi="10.17487/RFC0975", + } + +@misc{rfc976, + author="M.R. Horton", + title="{UUCP mail interchange format standard}", + howpublished="RFC 976", + series="Internet Request for Comments", + type="RFC", + number="976", + pages="1--12", + year=1986, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1137", +url="https://www.rfc-editor.org/rfc/rfc976.txt", + key="RFC 976", + abstract={This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone.}, + doi="10.17487/RFC0976", + } + +@misc{rfc977, + author="B. Kantor and P. Lapsley", + title="{Network News Transfer Protocol}", + howpublished="RFC 977 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="977", + pages="1--27", + year=1986, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3977", +url="https://www.rfc-editor.org/rfc/rfc977.txt", + key="RFC 977", + abstract={NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + keywords="NNTP]", + doi="10.17487/RFC0977", + } + +@misc{rfc978, + author="J.K. Reynolds and R. Gillman and W.A. Brackenridge and A. Witkowski and J. Postel", + title="{Voice File Interchange Protocol (VFIP)}", + howpublished="RFC 978", + series="Internet Request for Comments", + type="RFC", + number="978", + pages="1--5", + year=1986, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc978.txt", + key="RFC 978", + abstract={The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged.}, + doi="10.17487/RFC0978", + } + +@misc{rfc979, + author="A.G. Malis", + title="{PSN End-to-End functional specification}", + howpublished="RFC 979", + series="Internet Request for Comments", + type="RFC", + number="979", + pages="1--15", + year=1986, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc979.txt", + key="RFC 979", + abstract={This memo is an updated version of BBN Report 5775, ``End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET''. The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.}, + doi="10.17487/RFC0979", + } + +@misc{rfc980, + author="O.J. Jacobsen and J. Postel", + title="{Protocol document order information}", + howpublished="RFC 980", + series="Internet Request for Comments", + type="RFC", + number="980", + pages="1--12", + year=1986, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc980.txt", + key="RFC 980", + abstract={This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT).}, + doi="10.17487/RFC0980", + } + +@misc{rfc981, + author="D.L. Mills", + title="{Experimental multiple-path routing algorithm}", + howpublished="RFC 981", + series="Internet Request for Comments", + type="RFC", + number="981", + pages="1--22", + year=1986, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc981.txt", + key="RFC 981", + abstract={This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed.}, + doi="10.17487/RFC0981", + } + +@misc{rfc982, + author="H.W. Braun", + title="{Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address}", + howpublished="RFC 982", + series="Internet Request for Comments", + type="RFC", + number="982", + pages="1--11", + year=1986, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc982.txt", + key="RFC 982", + abstract={This RFC is a draft working document of the ANSI ``Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address''. It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet.}, + doi="10.17487/RFC0982", + } + +@misc{rfc983, + author="D.E. Cass and M.T. Rose", + title="{ISO transport arrives on top of the TCP}", + howpublished="RFC 983", + series="Internet Request for Comments", + type="RFC", + number="983", + pages="1--27", + year=1986, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1006", +url="https://www.rfc-editor.org/rfc/rfc983.txt", + key="RFC 983", + abstract={This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged.}, + doi="10.17487/RFC0983", + } + +@misc{rfc984, + author="D.D. Clark and M.L. Lambert", + title="{PCMAIL: A distributed mail system for personal computers}", + howpublished="RFC 984", + series="Internet Request for Comments", + type="RFC", + number="984", + pages="1--31", + year=1986, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 993", +url="https://www.rfc-editor.org/rfc/rfc984.txt", + key="RFC 984", + abstract={This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the ``repository''. The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993.}, + doi="10.17487/RFC0984", + } + +@misc{rfc985, + author="National Science Foundation and Network Technical Advisory Group", + title="{Requirements for Internet gateways - draft}", + howpublished="RFC 985", + series="Internet Request for Comments", + type="RFC", + number="985", + pages="1--23", + year=1986, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1009", +url="https://www.rfc-editor.org/rfc/rfc985.txt", + key="RFC 985", + abstract={This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification.}, + keywords="Requirements, Internet, gateways", + doi="10.17487/RFC0985", + } + +@misc{rfc986, + author="R.W. Callon and H.W. Braun", + title="{Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol}", + howpublished="RFC 986", + series="Internet Request for Comments", + type="RFC", + number="986", + pages="1--7", + year=1986, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1069", +url="https://www.rfc-editor.org/rfc/rfc986.txt", + key="RFC 986", + abstract={This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of ``ISO-grams'' in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0986", + } + +@misc{rfc987, + author="S.E. Kille", + title="{Mapping between X.400 and RFC 822}", + howpublished="RFC 987", + series="Internet Request for Comments", + type="RFC", + number="987", + pages="1--69", + year=1986, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2156, 1327, updated by RFCs 1026, 1138, 1148", +url="https://www.rfc-editor.org/rfc/rfc987.txt", + key="RFC 987", + abstract={The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC0987", + } + +@misc{rfc988, + author="S.E. Deering", + title="{Host extensions for IP multicasting}", + howpublished="RFC 988", + series="Internet Request for Comments", + type="RFC", + number="988", + pages="1--20", + year=1986, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1054, 1112", +url="https://www.rfc-editor.org/rfc/rfc988.txt", + key="RFC 988", + abstract={This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.}, + keywords="multicast, Internet", + doi="10.17487/RFC0988", + } + +@misc{rfc989, + author="J. Linn", + title="{Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures}", + howpublished="RFC 989", + series="Internet Request for Comments", + type="RFC", + number="989", + pages="1--23", + year=1987, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1040, 1113", +url="https://www.rfc-editor.org/rfc/rfc989.txt", + key="RFC 989", + abstract={This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.}, + doi="10.17487/RFC0989", + } + +@misc{rfc990, + author="J.K. Reynolds and J. Postel", + title="{Assigned numbers}", + howpublished="RFC 990 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="990", + pages="1--75", + year=1986, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1010, updated by RFC 997", +url="https://www.rfc-editor.org/rfc/rfc990.txt", + key="RFC 990", + abstract={This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.}, + doi="10.17487/RFC0990", + } + +@misc{rfc991, + author="J.K. Reynolds and J. Postel", + title="{Official ARPA-Internet protocols}", + howpublished="RFC 991", + series="Internet Request for Comments", + type="RFC", + number="991", + pages="1--46", + year=1986, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1011", +url="https://www.rfc-editor.org/rfc/rfc991.txt", + key="RFC 991", + abstract={This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.}, + doi="10.17487/RFC0991", + } + +@misc{rfc992, + author="K.P. Birman and T.A. Joseph", + title="{On communication support for fault tolerant process groups}", + howpublished="RFC 992", + series="Internet Request for Comments", + type="RFC", + number="992", + pages="1--18", + year=1986, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc992.txt", + key="RFC 992", + abstract={This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures.}, + doi="10.17487/RFC0992", + } + +@misc{rfc993, + author="D.D. Clark and M.L. Lambert", + title="{PCMAIL: A distributed mail system for personal computers}", + howpublished="RFC 993", + series="Internet Request for Comments", + type="RFC", + number="993", + pages="1--28", + year=1986, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1056", +url="https://www.rfc-editor.org/rfc/rfc993.txt", + key="RFC 993", + abstract={This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984.}, + doi="10.17487/RFC0993", + } + +@misc{rfc994, + author="International Organization for Standardization", + title="{Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service}", + howpublished="RFC 994", + series="Internet Request for Comments", + type="RFC", + number="994", + pages="1--52", + year=1986, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc994.txt", + key="RFC 994", + abstract={This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).}, + doi="10.17487/RFC0994", + } + +@misc{rfc995, + author="International Organization for Standardization", + title="{End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473}", + howpublished="RFC 995", + series="Internet Request for Comments", + type="RFC", + number="995", + pages="1--41", + year=1986, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc995.txt", + key="RFC 995", + abstract={This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer.}, + doi="10.17487/RFC0995", + } + +@misc{rfc996, + author="D.L. Mills", + title="{Statistics server}", + howpublished="RFC 996 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="996", + pages="1--3", + year=1987, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc996.txt", + key="RFC 996", + abstract={This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.}, + keywords="STATSRV", + doi="10.17487/RFC0996", + } + +@misc{rfc997, + author="J.K. Reynolds and J. Postel", + title="{Internet numbers}", + howpublished="RFC 997", + series="Internet Request for Comments", + type="RFC", + number="997", + pages="1--42", + year=1987, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1020, 1117", +url="https://www.rfc-editor.org/rfc/rfc997.txt", + key="RFC 997", + abstract={This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.}, + doi="10.17487/RFC0997", + } + +@misc{rfc998, + author="D.D. Clark and M.L. Lambert and L. Zhang", + title="{NETBLT: A bulk data transfer protocol}", + howpublished="RFC 998 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="998", + pages="1--21", + year=1987, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc998.txt", + key="RFC 998", + abstract={This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969.}, + keywords="NETBLT", + doi="10.17487/RFC0998", + } + +@misc{rfc999, + author="A. Westine and J. Postel", + title="{Requests For Comments summary notes: 900-999}", + howpublished="RFC 999", + series="Internet Request for Comments", + type="RFC", + number="999", + pages="1--22", + year=1987, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1000", +url="https://www.rfc-editor.org/rfc/rfc999.txt", + key="RFC 999", + doi="10.17487/RFC0999", + } + +@misc{rfc1000, + author="J.K. Reynolds and J. Postel", + title="{Request For Comments reference guide}", + howpublished="RFC 1000", + series="Internet Request for Comments", + type="RFC", + number="1000", + pages="1--149", + year=1987, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1000.txt", + key="RFC 1000", + abstract={This RFC Reference Guide is intended to provide a historical account by categorizing and summarizing of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. These documents have been crossed referenced to indicate which RFCs are current, obsolete, or revised.}, + doi="10.17487/RFC1000", + } + +@misc{rfc1001, + author="NetBIOS Working Group in the Defense Advanced Research Projects Agency and Internet Activities Board and End-to-End Services Task Force", + title="{Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods}", + howpublished="RFC 1001 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1001", + pages="1--68", + year=1987, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1001.txt", + key="RFC 1001", + abstract={This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, ``Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications''.}, + keywords="NETBIOS", + doi="10.17487/RFC1001", + } + +@misc{rfc1002, + author="NetBIOS Working Group in the Defense Advanced Research Projects Agency and Internet Activities Board and End-to-End Services Task Force", + title="{Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications}", + howpublished="RFC 1002 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1002", + pages="1--84", + year=1987, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1002.txt", + key="RFC 1002", + abstract={This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables. A more general overview is found in a companion RFC, ``Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods''.}, + keywords="NETBIOS", + doi="10.17487/RFC1002", + } + +@misc{rfc1003, + author="A.R. Katz", + title="{Issues in defining an equations representation standard}", + howpublished="RFC 1003", + series="Internet Request for Comments", + type="RFC", + number="1003", + pages="1--7", + year=1987, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1003.txt", + key="RFC 1003", + abstract={This memo is intended to identify and explore issues in defining a standard for the exchange of mathematical equations. No attempt is made at a complete definition and more questions are asked than are answered. Questions about the user interface are only addressed to the extent that they affect interchange issues.}, + doi="10.17487/RFC1003", + } + +@misc{rfc1004, + author="D.L. Mills", + title="{Distributed-protocol authentication scheme}", + howpublished="RFC 1004 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1004", + pages="1--8", + year=1987, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1004.txt", + key="RFC 1004", + abstract={The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.}, + keywords="COOKIE-JAR", + doi="10.17487/RFC1004", + } + +@misc{rfc1005, + author="A. Khanna and A.G. Malis", + title="{ARPANET AHIP-E Host Access Protocol (enhanced AHIP)}", + howpublished="RFC 1005", + series="Internet Request for Comments", + type="RFC", + number="1005", + pages="1--34", + year=1987, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1005.txt", + key="RFC 1005", + abstract={This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis.}, + doi="10.17487/RFC1005", + } + +@misc{rfc1006, + author="M.T. Rose and D.E. Cass", + title="{ISO Transport Service on top of the TCP Version: 3}", + howpublished="RFC 1006 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1006", + pages="1--19", + year=1987, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2126", +url="https://www.rfc-editor.org/rfc/rfc1006.txt", + key="RFC 1006", + abstract={This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible.}, + keywords="TP-TCP", + doi="10.17487/RFC1006", + } + +@misc{rfc1007, + author="W. McCoy", + title="{Military supplement to the ISO Transport Protocol}", + howpublished="RFC 1007", + series="Internet Request for Comments", + type="RFC", + number="1007", + pages="1--23", + year=1987, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1007.txt", + key="RFC 1007", + abstract={This document supplements the Transport Service and Protocol of the International Standards Organization (ISO), IS 8072 and IS 8073, respectively, and their formal descriptions by providing conventions, option selections and parameter values. This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.}, + doi="10.17487/RFC1007", + } + +@misc{rfc1008, + author="W. McCoy", + title="{Implementation guide for the ISO Transport Protocol}", + howpublished="RFC 1008", + series="Internet Request for Comments", + type="RFC", + number="1008", + pages="1--73", + year=1987, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1008.txt", + key="RFC 1008", + abstract={This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.}, + doi="10.17487/RFC1008", + } + +@misc{rfc1009, + author="R.T. Braden and J. Postel", + title="{Requirements for Internet gateways}", + howpublished="RFC 1009 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1009", + pages="1--54", + year=1987, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1812", +url="https://www.rfc-editor.org/rfc/rfc1009.txt", + key="RFC 1009", + abstract={This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community.}, + keywords="", + doi="10.17487/RFC1009", + } + +@misc{rfc1010, + author="J.K. Reynolds and J. Postel", + title="{Assigned numbers}", + howpublished="RFC 1010 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1010", + pages="1--44", + year=1987, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1060", +url="https://www.rfc-editor.org/rfc/rfc1010.txt", + key="RFC 1010", + abstract={This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.}, + doi="10.17487/RFC1010", + } + +@misc{rfc1011, + author="J.K. Reynolds and J. Postel", + title="{Official Internet protocols}", + howpublished="RFC 1011", + series="Internet Request for Comments", + type="RFC", + number="1011", + pages="1--52", + year=1987, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6093", +url="https://www.rfc-editor.org/rfc/rfc1011.txt", + key="RFC 1011", + abstract={This memo is an official status report on the protocols used in the Internet community. It identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned.}, + doi="10.17487/RFC1011", + } + +@misc{rfc1012, + author="J.K. Reynolds and J. Postel", + title="{Bibliography of Request For Comments 1 through 999}", + howpublished="RFC 1012 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1012", + pages="1--64", + year=1987, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1012.txt", + key="RFC 1012", + abstract={This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.}, + doi="10.17487/RFC1012", + } + +@misc{rfc1013, + author="R.W. Scheifler", + title="{X Window System Protocol, version 11: Alpha update April 1987}", + howpublished="RFC 1013", + series="Internet Request for Comments", + type="RFC", + number="1013", + pages="1--101", + year=1987, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1013.txt", + key="RFC 1013", + abstract={This RFC is distributed to the Internet community for information only. It does not establish an Internet standard. The X window system has been widely reviewed and tested. The Internet community is encouraged to experiment with it.}, + doi="10.17487/RFC1013", + } + +@misc{rfc1014, + author="Sun Microsystems", + title="{XDR: External Data Representation standard}", + howpublished="RFC 1014", + series="Internet Request for Comments", + type="RFC", + number="1014", + pages="1--20", + year=1987, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1014.txt", + key="RFC 1014", + abstract={XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures. XDR fits into ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing. This RFC is distributed for information only, it does not establish a Internet standard.}, + doi="10.17487/RFC1014", + } + +@misc{rfc1015, + author="B.M. Leiner", + title="{Implementation plan for interagency research Internet}", + howpublished="RFC 1015", + series="Internet Request for Comments", + type="RFC", + number="1015", + pages="1--24", + year=1987, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1015.txt", + key="RFC 1015", + abstract={This RFC proposes an Interagency Research Internet as the natural outgrowth of the current Internet. This is an ``idea paper'' and discussion is strongly encouraged.}, + doi="10.17487/RFC1015", + } + +@misc{rfc1016, + author="W. Prue and J. Postel", + title="{Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)}", + howpublished="RFC 1016", + series="Internet Request for Comments", + type="RFC", + number="1016", + pages="1--18", + year=1987, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1016.txt", + key="RFC 1016", + abstract={The memo is intended to explore the issue of what a host could do with a source quench. The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host. This is a ``crazy idea paper'' and discussion is essential.}, + doi="10.17487/RFC1016", + } + +@misc{rfc1017, + author="B.M. Leiner", + title="{Network requirements for scientific research: Internet task force on scientific computing}", + howpublished="RFC 1017", + series="Internet Request for Comments", + type="RFC", + number="1017", + pages="1--19", + year=1987, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1017.txt", + key="RFC 1017", + abstract={This RFC identifies the requirements on communication networks for supporting scientific research. It proposes some specific areas for near term work, as well as some long term goals. This is an ``idea'' paper and discussion is strongly encouraged.}, + doi="10.17487/RFC1017", + } + +@misc{rfc1018, + author="A.M. McKenzie", + title="{Some comments on SQuID}", + howpublished="RFC 1018", + series="Internet Request for Comments", + type="RFC", + number="1018", + pages="1--3", + year=1987, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1018.txt", + key="RFC 1018", + abstract={This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench. This memo introduces the distinction of the cause of congestion in a gateway between the effects of ``Funneling'' and ``Mismatch''. It is offered in the same spirit as RFC-1016; to stimulate discussion. The opinions offered are personal, not corporate, opinions. Distribution of this memo is unlimited.}, + doi="10.17487/RFC1018", + } + +@misc{rfc1019, + author="D. Arnon", + title="{Report of the Workshop on Environments for Computational Mathematics}", + howpublished="RFC 1019", + series="Internet Request for Comments", + type="RFC", + number="1019", + pages="1--8", + year=1987, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1019.txt", + key="RFC 1019", + abstract={This memo is a report on the discussion of the representation of equations in a workshop at the ACM SIGGRAPH Conference held in Anaheim, California on 30 July 1987.}, + doi="10.17487/RFC1019", + } + +@misc{rfc1020, + author="S. Romano and M.K. Stahl", + title="{Internet numbers}", + howpublished="RFC 1020", + series="Internet Request for Comments", + type="RFC", + number="1020", + pages="1--51", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1062, 1117, 1166", +url="https://www.rfc-editor.org/rfc/rfc1020.txt", + key="RFC 1020", + abstract={This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997.}, + doi="10.17487/RFC1020", + } + +@misc{rfc1021, + author="C. Partridge and G. Trewitt", + title="{High-level Entity Management System (HEMS)}", + howpublished="RFC 1021 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1021", + pages="1--5", + year=1987, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1021.txt", + key="RFC 1021", + abstract={This memo provides a general overview of the High-level Entity management system (HEMS). This system is experimental, and is currently being tested in portions of the Internet.}, + keywords="HEMS", + doi="10.17487/RFC1021", + } + +@misc{rfc1022, + author="C. Partridge and G. Trewitt", + title="{High-level Entity Management Protocol (HEMP)}", + howpublished="RFC 1022", + series="Internet Request for Comments", + type="RFC", + number="1022", + pages="1--12", + year=1987, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1022.txt", + key="RFC 1022", + abstract={This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines. This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021. This memo also assumes a knowledge of the ISO data encoding standard, ASN.1.}, + doi="10.17487/RFC1022", + } + +@misc{rfc1023, + author="G. Trewitt and C. Partridge", + title="{HEMS monitoring and control language}", + howpublished="RFC 1023", + series="Internet Request for Comments", + type="RFC", + number="1023", + pages="1--17", + year=1987, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1076", +url="https://www.rfc-editor.org/rfc/rfc1023.txt", + key="RFC 1023", + abstract={This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1.}, + doi="10.17487/RFC1023", + } + +@misc{rfc1024, + author="C. Partridge and G. Trewitt", + title="{HEMS variable definitions}", + howpublished="RFC 1024", + series="Internet Request for Comments", + type="RFC", + number="1024", + pages="1--74", + year=1987, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1024.txt", + key="RFC 1024", + abstract={This memo assigns instruction codes, defines object formats and object semantics for use with the High-Level Monitoring and Control Language, defined in RFC-1023. A general system has been described in previous memos (RFC-1021, RFC-1022). This system is called the High-Level Entity Management System (HEMS). This memo is provisional and the definitions are subject to change. Readers should confirm with the authors that they have the most recent version. This RFC assumes a working knowledge of the ISO data encoding standard, ASN.1, and a general understanding of the IP protocol suite.}, + doi="10.17487/RFC1024", + } + +@misc{rfc1025, + author="J. Postel", + title="{TCP and IP bake off}", + howpublished="RFC 1025", + series="Internet Request for Comments", + type="RFC", + number="1025", + pages="1--6", + year=1987, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1025.txt", + key="RFC 1025", + abstract={This memo describes some of the procedures, scoring and tests used in the TCP and IP bake offs held in the early development of these protocols. These procedures and tests may still be of use in testing newly implemented TCP and IP modules.}, + doi="10.17487/RFC1025", + } + +@misc{rfc1026, + author="S.E. Kille", + title="{Addendum to RFC 987: (Mapping between X.400 and RFC-822)}", + howpublished="RFC 1026", + series="Internet Request for Comments", + type="RFC", + number="1026", + pages="1--4", + year=1987, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2156, 1327, updated by RFCs 1138, 1148", +url="https://www.rfc-editor.org/rfc/rfc1026.txt", + key="RFC 1026", + abstract={This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.}, + doi="10.17487/RFC1026", + } + +@misc{rfc1027, + author="S. Carl-Mitchell and J.S. Quarterman", + title="{Using ARP to implement transparent subnet gateways}", + howpublished="RFC 1027", + series="Internet Request for Comments", + type="RFC", + number="1027", + pages="1--8", + year=1987, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1027.txt", + key="RFC 1027", + abstract={This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of ``Proxy ARP''.}, + doi="10.17487/RFC1027", + } + +@misc{rfc1028, + author="J. Davin and J.D. Case and M. Fedor and M.L. Schoffstall", + title="{Simple Gateway Monitoring Protocol}", + howpublished="RFC 1028 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1028", + pages="1--35", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1028.txt", + key="RFC 1028", + abstract={This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users. This proposal is intended only as an interim response to immediate gateway monitoring needs.}, + keywords="SGMP", + doi="10.17487/RFC1028", + } + +@misc{rfc1029, + author="G. Parr", + title="{More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets}", + howpublished="RFC 1029", + series="Internet Request for Comments", + type="RFC", + number="1029", + pages="1--17", + year=1988, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1029.txt", + key="RFC 1029", + abstract={This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring host address parameters in a Multi-Lan system of Ethernets. The problem is one which is appearing more and more regularly as the interconnected systems grow larger on Campuses and in Commercial Institutions. This RFC suggests a protocol enhancement for the Internet community, and requests discussion and suggestions for improvements.}, + keywords="arp", + doi="10.17487/RFC1029", + } + +@misc{rfc1030, + author="M.L. Lambert", + title="{On testing the NETBLT Protocol over divers networks}", + howpublished="RFC 1030", + series="Internet Request for Comments", + type="RFC", + number="1030", + pages="1--16", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1030.txt", + key="RFC 1030", + abstract={This memo describes the results gathered from testing NETBLT over three networks of different bandwidths and round-trip delays. The results are not complete, but the information gathered so far has not been promising. The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998.}, + doi="10.17487/RFC1030", + } + +@misc{rfc1031, + author="W.D. Lazear", + title="{MILNET name domain transition}", + howpublished="RFC 1031", + series="Internet Request for Comments", + type="RFC", + number="1031", + pages="1--10", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1031.txt", + key="RFC 1031", + abstract={This RFC consolidates information necessary for the implementation of domain style names throughout the DDN/MILNET Internet community. The introduction of domain style names will impact all hosts in the DDN/MILNET Internet. This RFC is designed as an aid to implementors and administrators by providing: 1) an overview of the transition process from host tables to domains, 2) a timetable for the transition, and 3) references to documentation and software relating to the domain system.}, + doi="10.17487/RFC1031", + } + +@misc{rfc1032, + author="M.K. Stahl", + title="{Domain administrators guide}", + howpublished="RFC 1032", + series="Internet Request for Comments", + type="RFC", + number="1032", + pages="1--14", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1032.txt", + key="RFC 1032", + abstract={Domains are administrative entities that provide decentralized management of host naming and addressing. The domain-naming system is distributed and hierarchical. This memo describes procedures for registering a domain with the Network Information Center (NIC) of Defense Data Network (DDN), and offers guidelines on the establishment and administration of a domain in accordance with the requirements specified in RFC-920. It is recommended that the guidelines described in this document be used by domain administrators in the establishment and control of second-level domains. The role of the domain administrator (DA) is that of coordinator, manager, and technician. If his domain is established at the second level or lower in the tree, the domain administrator must register by interacting with the management of the domain directly above this.}, + doi="10.17487/RFC1032", + } + +@misc{rfc1033, + author="M. Lottor", + title="{Domain Administrators Operations Guide}", + howpublished="RFC 1033", + series="Internet Request for Comments", + type="RFC", + number="1033", + pages="1--22", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1033.txt", + key="RFC 1033", + abstract={This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed (see RFCs 1031, 1032, 1034, and 1035).}, + doi="10.17487/RFC1033", + } + +@misc{rfc1034, + author="P.V. Mockapetris", + title="{Domain names - concepts and facilities}", + howpublished="RFC 1034 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1034", + pages="1--55", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4035, 4592, 5936, 8020", +url="https://www.rfc-editor.org/rfc/rfc1034.txt", + key="RFC 1034", + abstract={This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.}, + keywords="DOMAIN", + doi="10.17487/RFC1034", + } + +@misc{rfc1035, + author="P.V. Mockapetris", + title="{Domain names - implementation and specification}", + howpublished="RFC 1035 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1035", + pages="1--55", + year=1987, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766", +url="https://www.rfc-editor.org/rfc/rfc1035.txt", + key="RFC 1035", + abstract={This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.}, + keywords="DOMAIN, DNS", + doi="10.17487/RFC1035", + } + +@misc{rfc1036, + author="M.R. Horton and R. Adams", + title="{Standard for interchange of USENET messages}", + howpublished="RFC 1036", + series="Internet Request for Comments", + type="RFC", + number="1036", + pages="1--19", + year=1987, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5536, 5537", +url="https://www.rfc-editor.org/rfc/rfc1036.txt", + key="RFC 1036", + abstract={This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1036", + } + +@misc{rfc1037, + author="B. Greenberg and S. Keene", + title="{NFILE - a file access protocol}", + howpublished="RFC 1037 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1037", + pages="1--86", + year=1987, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1037.txt", + key="RFC 1037", + abstract={This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE.}, + keywords="NFILE", + doi="10.17487/RFC1037", + } + +@misc{rfc1038, + author="M. St. Johns", + title="{Draft revised IP security option}", + howpublished="RFC 1038", + series="Internet Request for Comments", + type="RFC", + number="1038", + pages="1--7", + year=1988, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1108", +url="https://www.rfc-editor.org/rfc/rfc1038.txt", + key="RFC 1038", + abstract={This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, ``Internet Protocol''.}, + doi="10.17487/RFC1038", + } + +@misc{rfc1039, + author="D. Latham", + title="{DoD statement on Open Systems Interconnection protocols}", + howpublished="RFC 1039", + series="Internet Request for Comments", + type="RFC", + number="1039", + pages="1--3", + year=1988, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1039.txt", + key="RFC 1039", + abstract={This RFC reproduces a memorandum issued on 2-JUL-87 from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC31) to the Director of the Defense Communications Agency (DCA). This memo is distributed for information only.}, + doi="10.17487/RFC1039", + } + +@misc{rfc1040, + author="J. Linn", + title="{Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures}", + howpublished="RFC 1040", + series="Internet Request for Comments", + type="RFC", + number="1040", + pages="1--29", + year=1988, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1113", +url="https://www.rfc-editor.org/rfc/rfc1040.txt", + key="RFC 1040", + abstract={This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.}, + doi="10.17487/RFC1040", + } + +@misc{rfc1041, + author="Y. Rekhter", + title="{Telnet 3270 regime option}", + howpublished="RFC 1041 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1041", + pages="1--6", + year=1988, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6270", +url="https://www.rfc-editor.org/rfc/rfc1041.txt", + key="RFC 1041", + abstract={This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.}, + keywords="TOPT-3270", + doi="10.17487/RFC1041", + } + +@misc{rfc1042, + author="J. Postel and J.K. Reynolds", + title="{Standard for the transmission of IP datagrams over IEEE 802 networks}", + howpublished="RFC 1042 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1042", + pages="1--15", + year=1988, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1042.txt", + key="RFC 1042", + abstract={This RFC specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on IEEE 802 Networks to allow compatible and interoperable implementations. This RFC specifies a protocol standard for the Internet community.}, + keywords="IP-IEEE", + doi="10.17487/RFC1042", + } + +@misc{rfc1043, + author="A. Yasuda and T. Thompson", + title="{Telnet Data Entry Terminal option: DODIIS implementation}", + howpublished="RFC 1043 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1043", + pages="1--26", + year=1988, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1043.txt", + key="RFC 1043", + abstract={This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged.}, + keywords="TOPT-DATA", + doi="10.17487/RFC1043", + } + +@misc{rfc1044, + author="K. Hardwick and J. Lekashman", + title="{Internet Protocol on Network System's HYPERchannel: Protocol Specification}", + howpublished="RFC 1044 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1044", + pages="1--43", + year=1988, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc1044.txt", + key="RFC 1044", + abstract={This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols.}, + keywords="IP-HC", + doi="10.17487/RFC1044", + } + +@misc{rfc1045, + author="D.R. Cheriton", + title="{VMTP: Versatile Message Transaction Protocol: Protocol specification}", + howpublished="RFC 1045 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1045", + pages="1--128", + year=1988, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1045.txt", + key="RFC 1045", + abstract={This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community.}, + keywords="VMTP", + doi="10.17487/RFC1045", + } + +@misc{rfc1046, + author="W. Prue and J. Postel", + title="{Queuing algorithm to provide type-of-service for IP links}", + howpublished="RFC 1046", + series="Internet Request for Comments", + type="RFC", + number="1046", + pages="1--11", + year=1988, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1046.txt", + key="RFC 1046", + abstract={This memo is intended to explore how Type-of-Service might be implemented in the Internet. The proposal describes a method of queuing which can provide the different classes of service. The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service. This is an ``idea paper'' and discussion is strongly encouraged.}, + doi="10.17487/RFC1046", + } + +@misc{rfc1047, + author="C. Partridge", + title="{Duplicate messages and SMTP}", + howpublished="RFC 1047", + series="Internet Request for Comments", + type="RFC", + number="1047", + pages="1--3", + year=1988, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1047.txt", + key="RFC 1047", + abstract={An examination of a synchronization problem in the Simple Mail Transfer Protocol (SMTP) is presented. This synchronization problem can cause a message to be delivered multiple times. A method for avoiding this problem is suggested. Nodding familiarity with the SMTP specification, RFC-821, is required.}, + doi="10.17487/RFC1047", + } + +@misc{rfc1048, + author="P.A. Prindeville", + title="{BOOTP vendor information extensions}", + howpublished="RFC 1048", + series="Internet Request for Comments", + type="RFC", + number="1048", + pages="1--7", + year=1988, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1084, 1395, 1497, 1533", +url="https://www.rfc-editor.org/rfc/rfc1048.txt", + key="RFC 1048", + abstract={This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought.}, + doi="10.17487/RFC1048", + } + +@misc{rfc1049, + author="M.A. Sirbu", + title="{Content-type header field for Internet messages}", + howpublished="RFC 1049 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1049", + pages="1--8", + year=1988, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1049.txt", + key="RFC 1049", + abstract={This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.}, + keywords="CONTENT", + doi="10.17487/RFC1049", + } + +@misc{rfc1050, + author="Sun Microsystems", + title="{RPC: Remote Procedure Call Protocol specification}", + howpublished="RFC 1050 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1050", + pages="1--24", + year=1988, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1057", +url="https://www.rfc-editor.org/rfc/rfc1050.txt", + key="RFC 1050", + abstract={This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time.}, + keywords="SUN-RPC", + doi="10.17487/RFC1050", + } + +@misc{rfc1051, + author="P.A. Prindeville", + title="{Standard for the transmission of IP datagrams and ARP packets over ARCNET networks}", + howpublished="RFC 1051 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1051", + pages="1--4", + year=1988, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1201", +url="https://www.rfc-editor.org/rfc/rfc1051.txt", + key="RFC 1051", + abstract={This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC1051", + } + +@misc{rfc1052, + author="V.G. Cerf", + title="{IAB recommendations for the development of Internet network management standards}", + howpublished="RFC 1052", + series="Internet Request for Comments", + type="RFC", + number="1052", + pages="1--14", + year=1988, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1052.txt", + key="RFC 1052", + abstract={This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. This memo does NOT, in and of itself, define or propose an Official Internet Protocol. It does reflect, however, the policy of the IAB with respect to further network management development in the short and long term.}, + doi="10.17487/RFC1052", + } + +@misc{rfc1053, + author="S. Levy and T. Jacobson", + title="{Telnet X.3 PAD option}", + howpublished="RFC 1053 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1053", + pages="1--21", + year=1988, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1053.txt", + key="RFC 1053", + abstract={This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.}, + keywords="TOPT-X.3", + doi="10.17487/RFC1053", + } + +@misc{rfc1054, + author="S.E. Deering", + title="{Host extensions for IP multicasting}", + howpublished="RFC 1054", + series="Internet Request for Comments", + type="RFC", + number="1054", + pages="1--19", + year=1988, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1112", +url="https://www.rfc-editor.org/rfc/rfc1054.txt", + key="RFC 1054", + abstract={This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a ``host group'', a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same ``best-efforts'' reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988.}, + doi="10.17487/RFC1054", + } + +@misc{rfc1055, + author="J.L. Romkey", + title="{Nonstandard for transmission of IP datagrams over serial lines: SLIP}", + howpublished="RFC 1055 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1055", + pages="1--6", + year=1988, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1055.txt", + key="RFC 1055", + abstract={The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard.}, + keywords="IP-SLIP", + doi="10.17487/RFC1055", + } + +@misc{rfc1056, + author="M.L. Lambert", + title="{PCMAIL: A distributed mail system for personal computers}", + howpublished="RFC 1056 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1056", + pages="1--38", + year=1988, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1056.txt", + key="RFC 1056", + abstract={This memo is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues.}, + keywords="PCMAIL", + doi="10.17487/RFC1056", + } + +@misc{rfc1057, + author="Sun Microsystems", + title="{RPC: Remote Procedure Call Protocol specification: Version 2}", + howpublished="RFC 1057 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1057", + pages="1--25", + year=1988, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1057.txt", + key="RFC 1057", + abstract={This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration. This memo is not an Internet standard at this time.}, + keywords="SUN-RPC", + doi="10.17487/RFC1057", + } + +@misc{rfc1058, + author="C.L. Hedrick", + title="{Routing Information Protocol}", + howpublished="RFC 1058 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1058", + pages="1--33", + year=1988, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1388, 1723", +url="https://www.rfc-editor.org/rfc/rfc1058.txt", + key="RFC 1058", + abstract={This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community.}, + keywords="RIP", + doi="10.17487/RFC1058", + } + +@misc{rfc1059, + author="D.L. Mills", + title="{Network Time Protocol (version 1) specification and implementation}", + howpublished="RFC 1059", + series="Internet Request for Comments", + type="RFC", + number="1059", + pages="1--58", + year=1988, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1119, 1305", +url="https://www.rfc-editor.org/rfc/rfc1059.txt", + key="RFC 1059", + abstract={This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accu racy 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.}, + keywords="NTP, NTPv1, time, clock, synchronization", + doi="10.17487/RFC1059", + } + +@misc{rfc1060, + author="J.K. Reynolds and J. Postel", + title="{Assigned numbers}", + howpublished="RFC 1060 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1060", + pages="1--86", + year=1990, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1340, updated by RFC 1349", +url="https://www.rfc-editor.org/rfc/rfc1060.txt", + key="RFC 1060", + abstract={This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.}, + doi="10.17487/RFC1060", + } + +@misc{rfc1062, + author="S. Romano and M.K. Stahl and M. Recker", + title="{Internet numbers}", + howpublished="RFC 1062", + series="Internet Request for Comments", + type="RFC", + number="1062", + pages="1--65", + year=1988, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1117, 1166", +url="https://www.rfc-editor.org/rfc/rfc1062.txt", + key="RFC 1062", + abstract={This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.}, + doi="10.17487/RFC1062", + } + +@misc{rfc1063, + author="J.C. Mogul and C.A. Kent and C. Partridge and K. McCloghrie", + title="{IP MTU discovery options}", + howpublished="RFC 1063", + series="Internet Request for Comments", + type="RFC", + number="1063", + pages="1--11", + year=1988, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1191", +url="https://www.rfc-editor.org/rfc/rfc1063.txt", + key="RFC 1063", + abstract={A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol.}, + doi="10.17487/RFC1063", + } + +@misc{rfc1064, + author="M.R. Crispin", + title="{Interactive Mail Access Protocol: Version 2}", + howpublished="RFC 1064", + series="Internet Request for Comments", + type="RFC", + number="1064", + pages="1--26", + year=1988, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1176, 1203", +url="https://www.rfc-editor.org/rfc/rfc1064.txt", + key="RFC 1064", + abstract={This memo suggests a method for workstations to dynamically access mail from a mailbox server (``respository''). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested.}, + doi="10.17487/RFC1064", + } + +@misc{rfc1065, + author="K. McCloghrie and M.T. Rose", + title="{Structure and identification of management information for TCP/IP-based internets}", + howpublished="RFC 1065 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1065", + pages="1--21", + year=1988, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1155", +url="https://www.rfc-editor.org/rfc/rfc1065.txt", + key="RFC 1065", + abstract={This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification.}, + doi="10.17487/RFC1065", + } + +@misc{rfc1066, + author="K. McCloghrie and M.T. Rose", + title="{Management Information Base for network management of TCP/IP-based internets}", + howpublished="RFC 1066", + series="Internet Request for Comments", + type="RFC", + number="1066", + pages="1--90", + year=1988, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1156", +url="https://www.rfc-editor.org/rfc/rfc1066.txt", + key="RFC 1066", + abstract={This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.}, + doi="10.17487/RFC1066", + } + +@misc{rfc1067, + author="J.D. Case and M. Fedor and M.L. Schoffstall and J. Davin", + title="{Simple Network Management Protocol}", + howpublished="RFC 1067", + series="Internet Request for Comments", + type="RFC", + number="1067", + pages="1--33", + year=1988, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1098", +url="https://www.rfc-editor.org/rfc/rfc1067.txt", + key="RFC 1067", + abstract={This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.}, + doi="10.17487/RFC1067", + } + +@misc{rfc1068, + author="A.L. DeSchon and R.T. Braden", + title="{Background File Transfer Program (BFTP)}", + howpublished="RFC 1068", + series="Internet Request for Comments", + type="RFC", + number="1068", + pages="1--27", + year=1988, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1068.txt", + key="RFC 1068", + abstract={This RFC describes an Internet background file transfer service that is built upon the third-party transfer model of FTP. No new protocols are involved. The purpose of this memo is to stimulate discussions on new Internet service modes.}, + keywords="FTP", + doi="10.17487/RFC1068", + } + +@misc{rfc1069, + author="R.W. Callon and H.W. Braun", + title="{Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol}", + howpublished="RFC 1069", + series="Internet Request for Comments", + type="RFC", + number="1069", + pages="1--10", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1069.txt", + key="RFC 1069", + abstract={This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet. This is a solution to one of the problems inherent in the use of ``ISO-grams'' in the Internet. This memo is a revision of RFC 986. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC1069", + } + +@misc{rfc1070, + author="R.A. Hagens and N.E. Hall and M.T. Rose", + title="{Use of the Internet as a subnetwork for experimentation with the OSI network layer}", + howpublished="RFC 1070", + series="Internet Request for Comments", + type="RFC", + number="1070", + pages="1--17", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1070.txt", + key="RFC 1070", + abstract={This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet and requests discussion and suggestions for improvements to this scenario. This RFC also proposes the creation of an experimental OSI internet. To participate in the experimental OSI internet, a system must abide by the agreements set forth in this RFC.}, + doi="10.17487/RFC1070", + } + +@misc{rfc1071, + author="R.T. Braden and D.A. Borman and C. Partridge", + title="{Computing the Internet checksum}", + howpublished="RFC 1071 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1071", + pages="1--24", + year=1988, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1141", +url="https://www.rfc-editor.org/rfc/rfc1071.txt", + key="RFC 1071", + abstract={This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.}, + doi="10.17487/RFC1071", + } + +@misc{rfc1072, + author="V. Jacobson and R.T. Braden", + title="{TCP extensions for long-delay paths}", + howpublished="RFC 1072 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1072", + pages="1--16", + year=1988, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1323, 2018, 6247", +url="https://www.rfc-editor.org/rfc/rfc1072.txt", + key="RFC 1072", + abstract={This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance.}, + doi="10.17487/RFC1072", + } + +@misc{rfc1073, + author="D. Waitzman", + title="{Telnet window size option}", + howpublished="RFC 1073 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1073", + pages="1--4", + year=1988, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1073.txt", + key="RFC 1073", + abstract={This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.}, + keywords="TOPT-NAWS", + doi="10.17487/RFC1073", + } + +@misc{rfc1074, + author="J. Rekhter", + title="{NSFNET backbone SPF based Interior Gateway Protocol}", + howpublished="RFC 1074", + series="Internet Request for Comments", + type="RFC", + number="1074", + pages="1--5", + year=1988, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1074.txt", + key="RFC 1074", + abstract={This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.}, + doi="10.17487/RFC1074", + } + +@misc{rfc1075, + author="D. Waitzman and C. Partridge and S.E. Deering", + title="{Distance Vector Multicast Routing Protocol}", + howpublished="RFC 1075 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1075", + pages="1--24", + year=1988, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1075.txt", + key="RFC 1075", + abstract={This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time.}, + keywords="IP-DVMRP", + doi="10.17487/RFC1075", + } + +@misc{rfc1076, + author="G. Trewitt and C. Partridge", + title="{HEMS monitoring and control language}", + howpublished="RFC 1076", + series="Internet Request for Comments", + type="RFC", + number="1076", + pages="1--42", + year=1988, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1076.txt", + key="RFC 1076", + abstract={This RFC specifies a query language for monitoring and control of network entities. This RFC supercedes RFC 1023, extending the query language and providing more discussion of the underlying issues. This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC 1021 and RFC 1022. Readers may wish to consult these RFCs when reading this memo. RFC 1024 contains detailed assignments of numbers and structures used in this system. Portions of RFC 1024 that define query language structures are superceded by definitions in this memo. This memo assumes a knowledge of the ISO data encoding standard, ASN.1.}, + doi="10.17487/RFC1076", + } + +@misc{rfc1077, + author="B.M. Leiner", + title="{Critical issues in high bandwidth networking}", + howpublished="RFC 1077", + series="Internet Request for Comments", + type="RFC", + number="1077", + pages="1--46", + year=1988, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1077.txt", + key="RFC 1077", + abstract={This memo presents the results of a working group on High Bandwidth Networking. This RFC is for your information and you are encouraged to comment on the issues presented.}, + doi="10.17487/RFC1077", + } + +@misc{rfc1078, + author="M. Lottor", + title="{TCP port service Multiplexer (TCPMUX)}", + howpublished="RFC 1078 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1078", + pages="1--2", + year=1988, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc1078.txt", + key="RFC 1078", + abstract={This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.}, + doi="10.17487/RFC1078", + } + +@misc{rfc1079, + author="C.L. Hedrick", + title="{Telnet terminal speed option}", + howpublished="RFC 1079 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1079", + pages="1--3", + year=1988, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1079.txt", + key="RFC 1079", + abstract={This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.}, + keywords="TOPT-TS", + doi="10.17487/RFC1079", + } + +@misc{rfc1080, + author="C.L. Hedrick", + title="{Telnet remote flow control option}", + howpublished="RFC 1080", + series="Internet Request for Comments", + type="RFC", + number="1080", + pages="1--4", + year=1988, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1372", +url="https://www.rfc-editor.org/rfc/rfc1080.txt", + key="RFC 1080", + abstract={This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard.}, + doi="10.17487/RFC1080", + } + +@misc{rfc1081, + author="M.T. Rose", + title="{Post Office Protocol: Version 3}", + howpublished="RFC 1081", + series="Internet Request for Comments", + type="RFC", + number="1081", + pages="1--16", + year=1988, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1225", +url="https://www.rfc-editor.org/rfc/rfc1081.txt", + key="RFC 1081", + abstract={This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC1081", + } + +@misc{rfc1082, + author="M.T. Rose", + title="{Post Office Protocol: Version 3: Extended service offerings}", + howpublished="RFC 1082", + series="Internet Request for Comments", + type="RFC", + number="1082", + pages="1--11", + year=1988, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1082.txt", + key="RFC 1082", + abstract={This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. All of the extensions described in this memo to the POP3 are OPTIONAL.}, + doi="10.17487/RFC1082", + } + +@misc{rfc1083, + author="Defense Advanced Research Projects Agency and Internet Activities Board", + title="{IAB official protocol standards}", + howpublished="RFC 1083 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1083", + pages="1--12", + year=1988, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1100", +url="https://www.rfc-editor.org/rfc/rfc1083.txt", + key="RFC 1083", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC1083", + } + +@misc{rfc1084, + author="J.K. Reynolds", + title="{BOOTP vendor information extensions}", + howpublished="RFC 1084", + series="Internet Request for Comments", + type="RFC", + number="1084", + pages="1--8", + year=1988, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1395, 1497, 1533", +url="https://www.rfc-editor.org/rfc/rfc1084.txt", + key="RFC 1084", + abstract={This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought.}, + doi="10.17487/RFC1084", + } + +@misc{rfc1085, + author="M.T. Rose", + title="{ISO presentation services on top of TCP/IP based internets}", + howpublished="RFC 1085", + series="Internet Request for Comments", + type="RFC", + number="1085", + pages="1--32", + year=1988, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1085.txt", + key="RFC 1085", + abstract={RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP/IP. Once this method is applied, one may implement ``real'' ISO applications on top of TCP/IP-based internets, by simply implementing OSI session, presentation, and application services on top of the transport service access point which is provided on top of the TCP. Although straight-forward, there are some environments in which the richness provided by the OSI application layer is desired, but it is nonetheless impractical to implement the underlying OSI infrastructure (i.e., the presentation, session, and transport services on top of the TCP). This memo describes an approach for providing ``stream-lined'' support of OSI application services on top of TCP/IP-based internets for such constrained environments. This memo proposes a standard for the Internet community.}, + doi="10.17487/RFC1085", + } + +@misc{rfc1086, + author="J.P. Onions and M.T. Rose", + title="{ISO-TP0 bridge between TCP and X.25}", + howpublished="RFC 1086", + series="Internet Request for Comments", + type="RFC", + number="1086", + pages="1--9", + year=1988, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1086.txt", + key="RFC 1086", + abstract={This memo proposes a standard for the Internet community. Hosts on the Internet that choose to implement ISO TP0 transport connectivity between TCP and X.25 based hosts are expected to experiment with this proposal. TCP port 146 is reserved for this proposal.}, + doi="10.17487/RFC1086", + } + +@misc{rfc1087, + author="Defense Advanced Research Projects Agency and Internet Activities Board", + title="{Ethics and the Internet}", + howpublished="RFC 1087", + series="Internet Request for Comments", + type="RFC", + number="1087", + pages="1--2", + year=1989, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1087.txt", + key="RFC 1087", + abstract={This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.}, + keywords="Ethics, Internet", + doi="10.17487/RFC1087", + } + +@misc{rfc1088, + author="L.J. McLaughlin", + title="{Standard for the transmission of IP datagrams over NetBIOS networks}", + howpublished="RFC 1088 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1088", + pages="1--3", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1088.txt", + key="RFC 1088", + abstract={This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.}, + keywords="IP-NETBIOS", + doi="10.17487/RFC1088", + } + +@misc{rfc1089, + author="M. Schoffstall and C. Davin and M. Fedor and J. Case", + title="{SNMP over Ethernet}", + howpublished="RFC 1089", + series="Internet Request for Comments", + type="RFC", + number="1089", + pages="1--3", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4789", +url="https://www.rfc-editor.org/rfc/rfc1089.txt", + key="RFC 1089", + abstract={This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer.}, + doi="10.17487/RFC1089", + } + +@misc{rfc1090, + author="R. Ullmann", + title="{SMTP on X.25}", + howpublished="RFC 1090", + series="Internet Request for Comments", + type="RFC", + number="1090", + pages="1--4", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1090.txt", + key="RFC 1090", + abstract={This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.}, + doi="10.17487/RFC1090", + } + +@misc{rfc1091, + author="J. VanBokkelen", + title="{Telnet terminal-type option}", + howpublished="RFC 1091 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1091", + pages="1--7", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1091.txt", + key="RFC 1091", + abstract={This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate}, + keywords="TOPT-TERM", + doi="10.17487/RFC1091", + } + +@misc{rfc1092, + author="J. Rekhter", + title="{EGP and policy based routing in the new NSFNET backbone}", + howpublished="RFC 1092", + series="Internet Request for Comments", + type="RFC", + number="1092", + pages="1--5", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1092.txt", + key="RFC 1092", + abstract={This memo discusses implementation decisions for routing issues in the NSFNET, especially in the NSFNET Backbone. Of special concern is the restriction of routing information to advertize the best route as established by a policy decision.}, + doi="10.17487/RFC1092", + } + +@misc{rfc1093, + author="H.W. Braun", + title="{NSFNET routing architecture}", + howpublished="RFC 1093", + series="Internet Request for Comments", + type="RFC", + number="1093", + pages="1--9", + year=1989, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1093.txt", + key="RFC 1093", + abstract={This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks.}, + doi="10.17487/RFC1093", + } + +@misc{rfc1094, + author="B. Nowicki", + title="{NFS: Network File System Protocol specification}", + howpublished="RFC 1094 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1094", + pages="1--27", + year=1989, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1094.txt", + key="RFC 1094", + abstract={This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.}, + keywords="SUN-NFS", + doi="10.17487/RFC1094", + } + +@misc{rfc1095, + author="U.S. Warrier and L. Besaw", + title="{Common Management Information Services and Protocol over TCP/IP (CMOT)}", + howpublished="RFC 1095", + series="Internet Request for Comments", + type="RFC", + number="1095", + pages="1--67", + year=1989, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1189", +url="https://www.rfc-editor.org/rfc/rfc1095.txt", + key="RFC 1095", + abstract={This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a compr ehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet.}, + doi="10.17487/RFC1095", + } + +@misc{rfc1096, + author="G.A. Marcy", + title="{Telnet X display location option}", + howpublished="RFC 1096 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1096", + pages="1--3", + year=1989, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1096.txt", + key="RFC 1096", + abstract={This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.}, + keywords="TOPT-XDL", + doi="10.17487/RFC1096", + } + +@misc{rfc1097, + author="B. Miller", + title="{Telnet subliminal-message option}", + howpublished="RFC 1097", + series="Internet Request for Comments", + type="RFC", + number="1097", + pages="1--3", + year=1989, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1097.txt", + key="RFC 1097", + abstract={This RFC specifies a standard for the Internet community. Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard.}, + doi="10.17487/RFC1097", + } + +@misc{rfc1098, + author="J.D. Case and M. Fedor and M.L. Schoffstall and J. Davin", + title="{Simple Network Management Protocol (SNMP)}", + howpublished="RFC 1098", + series="Internet Request for Comments", + type="RFC", + number="1098", + pages="1--34", + year=1989, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1157", +url="https://www.rfc-editor.org/rfc/rfc1098.txt", + key="RFC 1098", + abstract={This RFC is a re-release of RFC 1067, with a changed ``Status of this Memo'' section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.}, + doi="10.17487/RFC1098", + } + +@misc{rfc1099, + author="J. Reynolds", + title="{Request for Comments Summary: RFC Numbers 1000-1099}", + howpublished="RFC 1099 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1099", + pages="1--22", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1099.txt", + key="RFC 1099", + doi="10.17487/RFC1099", + } + +@misc{rfc1100, + author="Defense Advanced Research Projects Agency and Internet Activities Board", + title="{IAB official protocol standards}", + howpublished="RFC 1100 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1100", + pages="1--14", + year=1989, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1130", +url="https://www.rfc-editor.org/rfc/rfc1100.txt", + key="RFC 1100", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89.}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC1100", + } + +@misc{rfc1101, + author="P.V. Mockapetris", + title="{DNS encoding of network names and other types}", + howpublished="RFC 1101", + series="Internet Request for Comments", + type="RFC", + number="1101", + pages="1--14", + year=1989, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1101.txt", + key="RFC 1101", + abstract={This RFC proposes two extensions to the Domain Name System: - A specific method for entering and retrieving RRs which map between network names and numbers. - Ideas for a general method for describing mappings between arbitrary identifiers and numbers. The method for mapping between network names and addresses is a proposed standard, the ideas for a general method are experimental.}, + doi="10.17487/RFC1101", + } + +@misc{rfc1102, + author="D.D. Clark", + title="{Policy routing in Internet protocols}", + howpublished="RFC 1102", + series="Internet Request for Comments", + type="RFC", + number="1102", + pages="1--22", + year=1989, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1102.txt", + key="RFC 1102", + abstract={The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet.}, + doi="10.17487/RFC1102", + } + +@misc{rfc1103, + author="D. Katz", + title="{Proposed standard for the transmission of IP datagrams over FDDI Networks}", + howpublished="RFC 1103", + series="Internet Request for Comments", + type="RFC", + number="1103", + pages="1--9", + year=1989, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1188", +url="https://www.rfc-editor.org/rfc/rfc1103.txt", + key="RFC 1103", + abstract={This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]}, + doi="10.17487/RFC1103", + } + +@misc{rfc1104, + author="H.W. Braun", + title="{Models of policy based routing}", + howpublished="RFC 1104", + series="Internet Request for Comments", + type="RFC", + number="1104", + pages="1--10", + year=1989, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1104.txt", + key="RFC 1104", + abstract={The purpose of this RFC is to outline a variety of models for policy based routing. The relative benefits of the different approaches are reviewed. Discussions and comments are explicitly encouraged to move toward the best policy based routing model that scales well within a large internetworking environment.}, + doi="10.17487/RFC1104", + } + +@misc{rfc1105, + author="K. Lougheed and Y. Rekhter", + title="{Border Gateway Protocol (BGP)}", + howpublished="RFC 1105 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1105", + pages="1--17", + year=1989, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1163", +url="https://www.rfc-editor.org/rfc/rfc1105.txt", + key="RFC 1105", + abstract={This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]}, + keywords="BGP", + doi="10.17487/RFC1105", + } + +@misc{rfc1106, + author="R. Fox", + title="{TCP big window and NAK options}", + howpublished="RFC 1106 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1106", + pages="1--13", + year=1989, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6247", +url="https://www.rfc-editor.org/rfc/rfc1106.txt", + key="RFC 1106", + abstract={This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product. The extensions described in this document have been implemented and shown to work using resources at NASA. This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research.}, + doi="10.17487/RFC1106", + } + +@misc{rfc1107, + author="K.R. Sollins", + title="{Plan for Internet directory services}", + howpublished="RFC 1107 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1107", + pages="1--19", + year=1989, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1107.txt", + key="RFC 1107", + abstract={This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community.}, + doi="10.17487/RFC1107", + } + +@misc{rfc1108, + author="S. Kent", + title="{U.S. Department of Defense Security Options for the Internet Protocol}", + howpublished="RFC 1108 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1108", + pages="1--17", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1108.txt", + key="RFC 1108", + abstract={This RFC specifies the U.S. Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038, ``Revised IP Security Option'', dated January 1988. [STANDARDS-TRACK]}, + keywords="IPSO", + doi="10.17487/RFC1108", + } + +@misc{rfc1109, + author="V.G. Cerf", + title="{Report of the second Ad Hoc Network Management Review Group}", + howpublished="RFC 1109", + series="Internet Request for Comments", + type="RFC", + number="1109", + pages="1--8", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1109.txt", + key="RFC 1109", + abstract={This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet. This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989. The results of the first such meeting were reported in RFC 1052.}, + doi="10.17487/RFC1109", + } + +@misc{rfc1110, + author="A.M. McKenzie", + title="{Problem with the TCP big window option}", + howpublished="RFC 1110 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1110", + pages="1--3", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6247", +url="https://www.rfc-editor.org/rfc/rfc1110.txt", + key="RFC 1110", + abstract={This memo comments on the TCP Big Window option described in RFC 1106.}, + doi="10.17487/RFC1110", + } + +@misc{rfc1111, + author="J. Postel", + title="{Request for comments on Request for Comments: Instructions to RFC authors}", + howpublished="RFC 1111 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1111", + pages="1--6", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1543, 2223", +url="https://www.rfc-editor.org/rfc/rfc1111.txt", + key="RFC 1111", + abstract={This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.}, + doi="10.17487/RFC1111", + } + +@misc{rfc1112, + author="S.E. Deering", + title="{Host extensions for IP multicasting}", + howpublished="RFC 1112 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1112", + pages="1--17", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2236", +url="https://www.rfc-editor.org/rfc/rfc1112.txt", + key="RFC 1112", + abstract={This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]}, + keywords="IGMP, multicast", + doi="10.17487/RFC1112", + } + +@misc{rfc1113, + author="J. Linn", + title="{Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures}", + howpublished="RFC 1113 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1113", + pages="1--34", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1421", +url="https://www.rfc-editor.org/rfc/rfc1113.txt", + key="RFC 1113", + abstract={This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC1113", + } + +@misc{rfc1114, + author="S.T. Kent and J. Linn", + title="{Privacy enhancement for Internet electronic mail: Part II - certificate-based key management}", + howpublished="RFC 1114 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1114", + pages="1--25", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1422", +url="https://www.rfc-editor.org/rfc/rfc1114.txt", + key="RFC 1114", + abstract={This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC1114", + } + +@misc{rfc1115, + author="J. Linn", + title="{Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers}", + howpublished="RFC 1115 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1115", + pages="1--8", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1423", +url="https://www.rfc-editor.org/rfc/rfc1115.txt", + key="RFC 1115", + abstract={This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC1115", + } + +@misc{rfc1116, + author="D.A. Borman", + title="{Telnet Linemode option}", + howpublished="RFC 1116 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1116", + pages="1--21", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1184", +url="https://www.rfc-editor.org/rfc/rfc1116.txt", + key="RFC 1116", + abstract={Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]}, + doi="10.17487/RFC1116", + } + +@misc{rfc1117, + author="S. Romano and M.K. Stahl and M. Recker", + title="{Internet numbers}", + howpublished="RFC 1117 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1117", + pages="1--109", + year=1989, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1166", +url="https://www.rfc-editor.org/rfc/rfc1117.txt", + key="RFC 1117", + abstract={This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.}, + doi="10.17487/RFC1117", + } + +@misc{rfc1118, + author="E. Krol", + title="{Hitchhikers guide to the Internet}", + howpublished="RFC 1118 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1118", + pages="1--24", + year=1989, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1118.txt", + key="RFC 1118", + abstract={This RFC is being distributed to members of the Internet community in order to make available some ``hints'' which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo.}, + doi="10.17487/RFC1118", + } + +@misc{rfc1119, + author="D.L. Mills", + title="{Network Time Protocol (version 2) specification and implementation}", + howpublished="RFC 1119 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1119", + pages="1--1", + year=1989, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1305", +url="https://www.rfc-editor.org/rfc/rfc1119.txt", + key="RFC 1119", + abstract={This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK]}, + keywords="NTP, NTPv2, time, clock, synchronization", + doi="10.17487/RFC1119", + } + +@misc{rfc1120, + author="V. Cerf", + title="{Internet Activities Board}", + howpublished="RFC 1120 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1120", + pages="1--11", + year=1989, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1160", +url="https://www.rfc-editor.org/rfc/rfc1120.txt", + key="RFC 1120", + abstract={This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard.}, + doi="10.17487/RFC1120", + } + +@misc{rfc1121, + author="J. Postel and L. Kleinrock and V.G. Cerf and B. Boehm", + title="{Act one - the poems}", + howpublished="RFC 1121 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1121", + pages="1--6", + year=1989, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1121.txt", + key="RFC 1121", + abstract={This RFC presents a collection of poems that were presented at ``Act One'', a symposium held partially in celebration of the 20th anniversary of the ARPANET.}, + doi="10.17487/RFC1121", + } + +@misc{rfc1122, + author="R. {Braden (Ed.)}", + title="{Requirements for Internet Hosts - Communication Layers}", + howpublished="RFC 1122 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1122", + pages="1--116", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029", +url="https://www.rfc-editor.org/rfc/rfc1122.txt", + key="RFC 1122", + abstract={This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]}, + keywords="applicability", + doi="10.17487/RFC1122", + } + +@misc{rfc1123, + author="R. {Braden (Ed.)}", + title="{Requirements for Internet Hosts - Application and Support}", + howpublished="RFC 1123 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1123", + pages="1--98", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1349, 2181, 5321, 5966, 7766", +url="https://www.rfc-editor.org/rfc/rfc1123.txt", + key="RFC 1123", + abstract={This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]}, + keywords="applicability", + doi="10.17487/RFC1123", + } + +@misc{rfc1124, + author="B.M. Leiner", + title="{Policy issues in interconnecting networks}", + howpublished="RFC 1124", + series="Internet Request for Comments", + type="RFC", + number="1124", + pages="1--1", + year=1989, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1124.txt", + key="RFC 1124", + abstract={To support the activities of the Federal Research Internet Coordinating Committee (FRICC) in creating an interconnected set of networks to serve the research community, two workshops were held to address the technical support of policy issues that arise when interconnecting such networks. Held under the suspices of the Internet Activities Board at the request of the FRICC, and sponsored by NASA through RIACS, the workshops addressed the required and feasible technologies and architectures that could be used to satisfy the desired policies for interconnection. The purpose of this RFC is to report the results of these workshops.}, + doi="10.17487/RFC1124", + } + +@misc{rfc1125, + author="D. Estrin", + title="{Policy requirements for inter Administrative Domain routing}", + howpublished="RFC 1125", + series="Internet Request for Comments", + type="RFC", + number="1125", + pages="1--21", + year=1989, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1125.txt", + key="RFC 1125", + abstract={The purpose of this memo is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the development and adoption of standards.}, + doi="10.17487/RFC1125", + } + +@misc{rfc1126, + author="M. Little", + title="{Goals and functional requirements for inter-autonomous system routing}", + howpublished="RFC 1126", + series="Internet Request for Comments", + type="RFC", + number="1126", + pages="1--25", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1126.txt", + key="RFC 1126", + abstract={This document describes the functional requirements for a routing protocol to be used between autonomous systems. This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols. It is intended that these requirements will form the basis for the future development of a new inter-autonomous systems routing architecture and protocol. This memo does not specify a standard.}, + doi="10.17487/RFC1126", + } + +@misc{rfc1127, + author="R.T. Braden", + title="{Perspective on the Host Requirements RFCs}", + howpublished="RFC 1127 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1127", + pages="1--20", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1127.txt", + key="RFC 1127", + abstract={This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.}, + doi="10.17487/RFC1127", + } + +@misc{rfc1128, + author="D.L. Mills", + title="{Measured performance of the Network Time Protocol in the Internet system}", + howpublished="RFC 1128", + series="Internet Request for Comments", + type="RFC", + number="1128", + pages="1--1", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1128.txt", + key="RFC 1128", + abstract={This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific. The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119. NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave. In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio. The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications. For those hosts that support NTP, the experiments determine the d istribution 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.}, + doi="10.17487/RFC1128", + } + +@misc{rfc1129, + author="D.L. Mills", + title="{Internet Time Synchronization: The Network Time Protocol}", + howpublished="RFC 1129 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1129", + pages="1--1", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1129.txt", + key="RFC 1129", + abstract={This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of millisec onds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119.}, + keywords="NTP", + doi="10.17487/RFC1129", + } + +@misc{rfc1130, + author="Defense Advanced Research Projects Agency and Internet Activities Board", + title="{IAB official protocol standards}", + howpublished="RFC 1130 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1130", + pages="1--17", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1140", +url="https://www.rfc-editor.org/rfc/rfc1130.txt", + key="RFC 1130", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC1130", + } + +@misc{rfc1131, + author="J. Moy", + title="{OSPF specification}", + howpublished="RFC 1131 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1131", + pages="1--1", + year=1989, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1247", +url="https://www.rfc-editor.org/rfc/rfc1131.txt", + key="RFC 1131", + abstract={This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]}, + doi="10.17487/RFC1131", + } + +@misc{rfc1132, + author="L.J. McLaughlin", + title="{Standard for the transmission of 802.2 packets over IPX networks}", + howpublished="RFC 1132 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1132", + pages="1--4", + year=1989, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1132.txt", + key="RFC 1132", + abstract={This document specifies a standard method of encapsulating 802.2 packets on networks supporting Novell's Internet Packet Exchange Protocol (IPX). It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks. It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges.}, + keywords="IP-IPX", + doi="10.17487/RFC1132", + } + +@misc{rfc1133, + author="J.Y. Yu and H.W. Braun", + title="{Routing between the NSFNET and the DDN}", + howpublished="RFC 1133 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1133", + pages="1--10", + year=1989, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1133.txt", + key="RFC 1133", + abstract={This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo.}, + doi="10.17487/RFC1133", + } + +@misc{rfc1134, + author="D. Perkins", + title="{Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links}", + howpublished="RFC 1134 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1134", + pages="1--38", + year=1989, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1171", +url="https://www.rfc-editor.org/rfc/rfc1134.txt", + key="RFC 1134", + abstract={This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. [STANDARDS-TRACK]}, + doi="10.17487/RFC1134", + } + +@misc{rfc1135, + author="J.K. Reynolds", + title="{Helminthiasis of the Internet}", + howpublished="RFC 1135 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1135", + pages="1--33", + year=1989, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1135.txt", + key="RFC 1135", + abstract={This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included.}, + doi="10.17487/RFC1135", + } + +@misc{rfc1136, + author="S. Hares and D. Katz", + title="{Administrative Domains and Routing Domains: A model for routing in the Internet}", + howpublished="RFC 1136 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1136", + pages="1--10", + year=1989, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1136.txt", + key="RFC 1136", + abstract={This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the ``OSI Routeing Framework''. This memo does not specify an Internet standard.}, + doi="10.17487/RFC1136", + } + +@misc{rfc1137, + author="S. Kille", + title="{Mapping between full RFC 822 and RFC 822 with restricted encoding}", + howpublished="RFC 1137 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1137", + pages="1--3", + year=1989, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1137.txt", + key="RFC 1137", + abstract={This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard.}, + keywords="", + doi="10.17487/RFC1137", + } + +@misc{rfc1138, + author="S.E. Kille", + title="{Mapping between X.400(1988) / ISO 10021 and RFC 822}", + howpublished="RFC 1138 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1138", + pages="1--92", + year=1989, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2156, 1327, updated by RFC 1148", +url="https://www.rfc-editor.org/rfc/rfc1138.txt", + key="RFC 1138", + abstract={Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026.}, + doi="10.17487/RFC1138", + } + +@misc{rfc1139, + author="R.A. Hagens", + title="{Echo function for ISO 8473}", + howpublished="RFC 1139 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1139", + pages="1--6", + year=1990, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1574, 1575", +url="https://www.rfc-editor.org/rfc/rfc1139.txt", + key="RFC 1139", + abstract={This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item. When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard. This memo is not intended to compete with an ISO standard. [STANDARDS-TRACK]}, + doi="10.17487/RFC1139", + } + +@misc{rfc1140, + author="Defense Advanced Research Projects Agency and Internet Activities Board", + title="{IAB official protocol standards}", + howpublished="RFC 1140 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1140", + pages="1--27", + year=1990, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1200", +url="https://www.rfc-editor.org/rfc/rfc1140.txt", + key="RFC 1140", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90.}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC1140", + } + +@misc{rfc1141, + author="T. Mallory and A. Kullberg", + title="{Incremental updating of the Internet checksum}", + howpublished="RFC 1141 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1141", + pages="1--2", + year=1990, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1624", +url="https://www.rfc-editor.org/rfc/rfc1141.txt", + key="RFC 1141", + abstract={This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique.}, + doi="10.17487/RFC1141", + } + +@misc{rfc1142, + author="D. {Oran (Ed.)}", + title="{OSI IS-IS Intra-domain Routing Protocol}", + howpublished="RFC 1142 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1142", + pages="1--517", + year=1990, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7142", +url="https://www.rfc-editor.org/rfc/rfc1142.txt", + key="RFC 1142", + abstract={This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.}, + keywords="Domain, Routing, ISO", + doi="10.17487/RFC1142", + } + +@misc{rfc1143, + author="D.J. Bernstein", + title="{The Q Method of Implementing TELNET Option Negotiation}", + howpublished="RFC 1143 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1143", + pages="1--10", + year=1990, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1143.txt", + key="RFC 1143", + abstract={This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol.}, + keywords="", + doi="10.17487/RFC1143", + } + +@misc{rfc1144, + author="V. Jacobson", + title="{Compressing TCP/IP Headers for Low-Speed Serial Links}", + howpublished="RFC 1144 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1144", + pages="1--49", + year=1990, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1144.txt", + key="RFC 1144", + abstract={This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS-TRACK]}, + keywords="IP-CMPRS", + doi="10.17487/RFC1144", + } + +@misc{rfc1145, + author="J. Zweig and C. Partridge", + title="{TCP alternate checksum options}", + howpublished="RFC 1145 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1145", + pages="1--5", + year=1990, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1146, 6247", +url="https://www.rfc-editor.org/rfc/rfc1145.txt", + key="RFC 1145", + abstract={This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use.}, + doi="10.17487/RFC1145", + } + +@misc{rfc1146, + author="J. Zweig and C. Partridge", + title="{TCP alternate checksum options}", + howpublished="RFC 1146 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1146", + pages="1--5", + year=1990, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6247", +url="https://www.rfc-editor.org/rfc/rfc1146.txt", + key="RFC 1146", + abstract={This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145.}, + keywords="TCP-ACO", + doi="10.17487/RFC1146", + } + +@misc{rfc1147, + author="R.H. Stine", + title="{FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices}", + howpublished="RFC 1147 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1147", + pages="1--177", + year=1990, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1470", +url="https://www.rfc-editor.org/rfc/rfc1147.txt", + key="RFC 1147", + abstract={The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained.}, + doi="10.17487/RFC1147", + } + +@misc{rfc1148, + author="S.E. Kille", + title="{Mapping between X.400(1988) / ISO 10021 and RFC 822}", + howpublished="RFC 1148 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1148", + pages="1--94", + year=1990, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2156, 1327", +url="https://www.rfc-editor.org/rfc/rfc1148.txt", + key="RFC 1148", + abstract={This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.}, + doi="10.17487/RFC1148", + } + +@misc{rfc1149, + author="D. Waitzman", + title="{Standard for the transmission of IP datagrams on avian carriers}", + howpublished="RFC 1149 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1149", + pages="1--2", + year=1990, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2549, 6214", +url="https://www.rfc-editor.org/rfc/rfc1149.txt", + key="RFC 1149", + abstract={This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard.}, + keywords="avian, carrier, april, fools", + doi="10.17487/RFC1149", + } + +@misc{rfc1150, + author="G.S. Malkin and J.K. Reynolds", + title="{FYI on FYI: Introduction to the FYI Notes}", + howpublished="RFC 1150 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1150", + pages="1--4", + year=1990, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6360", +url="https://www.rfc-editor.org/rfc/rfc1150.txt", + key="RFC 1150", + abstract={This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.]}, + doi="10.17487/RFC1150", + } + +@misc{rfc1151, + author="C. Partridge and R.M. Hinden", + title="{Version 2 of the Reliable Data Protocol (RDP)}", + howpublished="RFC 1151 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1151", + pages="1--4", + year=1990, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1151.txt", + key="RFC 1151", + abstract={This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental.}, + keywords="RDP", + doi="10.17487/RFC1151", + } + +@misc{rfc1152, + author="C. Partridge", + title="{Workshop report: Internet research steering group workshop on very-high-speed networks}", + howpublished="RFC 1152 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1152", + pages="1--23", + year=1990, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1152.txt", + key="RFC 1152", + abstract={This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard.}, + doi="10.17487/RFC1152", + } + +@misc{rfc1153, + author="F.J. Wancho", + title="{Digest message format}", + howpublished="RFC 1153 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1153", + pages="1--4", + year=1990, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1153.txt", + key="RFC 1153", + abstract={This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.}, + keywords="DMF-MAIL", + doi="10.17487/RFC1153", + } + +@misc{rfc1154, + author="D. Robinson and R. Ullmann", + title="{Encoding header field for internet messages}", + howpublished="RFC 1154 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1154", + pages="1--7", + year=1990, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1505", +url="https://www.rfc-editor.org/rfc/rfc1154.txt", + key="RFC 1154", + abstract={This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).}, + doi="10.17487/RFC1154", + } + +@misc{rfc1155, + author="M.T. Rose and K. McCloghrie", + title="{Structure and identification of management information for TCP/IP-based internets}", + howpublished="RFC 1155 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1155", + pages="1--22", + year=1990, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1155.txt", + key="RFC 1155", + abstract={This RFC is a re-release of RFC 1065, with a changed ``Status of this Memo'', plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK]}, + keywords="SMI", + doi="10.17487/RFC1155", + } + +@misc{rfc1156, + author="K. McCloghrie and M.T. Rose", + title="{Management Information Base for network management of TCP/IP-based internets}", + howpublished="RFC 1156 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1156", + pages="1--91", + year=1990, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1156.txt", + key="RFC 1156", + abstract={This RFC is a re-release of RFC 1066, with a changed ``Status of this Memo'', ``IAB Policy Statement'', and ``Introduction'' sections plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK]}, + keywords="MIB-I", + doi="10.17487/RFC1156", + } + +@misc{rfc1157, + author="J.D. Case and M. Fedor and M.L. Schoffstall and J. Davin", + title="{Simple Network Management Protocol (SNMP)}", + howpublished="RFC 1157 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1157", + pages="1--36", + year=1990, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1157.txt", + key="RFC 1157", + abstract={This RFC is a re-release of RFC 1098, with a changed ``Status of this Memo'' section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]}, + keywords="SNMP", + doi="10.17487/RFC1157", + } + +@misc{rfc1158, + author="M.T. Rose", + title="{Management Information Base for network management of TCP/IP-based internets: MIB-II}", + howpublished="RFC 1158 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1158", + pages="1--133", + year=1990, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1213", +url="https://www.rfc-editor.org/rfc/rfc1158.txt", + key="RFC 1158", + abstract={This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]}, + doi="10.17487/RFC1158", + } + +@misc{rfc1159, + author="R. Nelson", + title="{Message Send Protocol}", + howpublished="RFC 1159 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1159", + pages="1--2", + year=1990, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1312", +url="https://www.rfc-editor.org/rfc/rfc1159.txt", + key="RFC 1159", + abstract={This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.}, + doi="10.17487/RFC1159", + } + +@misc{rfc1160, + author="V. Cerf", + title="{Internet Activities Board}", + howpublished="RFC 1160 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1160", + pages="1--11", + year=1990, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1160.txt", + key="RFC 1160", + abstract={This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.}, + doi="10.17487/RFC1160", + } + +@misc{rfc1161, + author="M.T. Rose", + title="{SNMP over OSI}", + howpublished="RFC 1161 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1161", + pages="1--8", + year=1990, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1418", +url="https://www.rfc-editor.org/rfc/rfc1161.txt", + key="RFC 1161", + abstract={This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,}, + doi="10.17487/RFC1161", + } + +@misc{rfc1162, + author="G. Satz", + title="{Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base}", + howpublished="RFC 1162 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1162", + pages="1--70", + year=1990, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1238", +url="https://www.rfc-editor.org/rfc/rfc1162.txt", + key="RFC 1162", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community.}, + doi="10.17487/RFC1162", + } + +@misc{rfc1163, + author="K. Lougheed and Y. Rekhter", + title="{Border Gateway Protocol (BGP)}", + howpublished="RFC 1163 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1163", + pages="1--29", + year=1990, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1267", +url="https://www.rfc-editor.org/rfc/rfc1163.txt", + key="RFC 1163", + abstract={This RFC, together with its companion RFC-1164, ``Application of the Border Gateway Protocol in the Internet'', specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]}, + keywords="BGP", + doi="10.17487/RFC1163", + } + +@misc{rfc1164, + author="J.C. Honig and D. Katz and M. Mathis and Y. Rekhter and J.Y. Yu", + title="{Application of the Border Gateway Protocol in the Internet}", + howpublished="RFC 1164 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1164", + pages="1--23", + year=1990, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1268", +url="https://www.rfc-editor.org/rfc/rfc1164.txt", + key="RFC 1164", + abstract={This RFC, together with its companion RFC-1163, ``A Border Gateway Protocol (BGP)'', specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]}, + keywords="BGP", + doi="10.17487/RFC1164", + } + +@misc{rfc1165, + author="J. Crowcroft and J.P. Onions", + title="{Network Time Protocol (NTP) over the OSI Remote Operations Service}", + howpublished="RFC 1165 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1165", + pages="1--10", + year=1990, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1165.txt", + key="RFC 1165", + abstract={This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.}, + keywords="NTP-OSI", + doi="10.17487/RFC1165", + } + +@misc{rfc1166, + author="S. Kirkpatrick and M.K. Stahl and M. Recker", + title="{Internet numbers}", + howpublished="RFC 1166 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1166", + pages="1--182", + year=1990, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5737", +url="https://www.rfc-editor.org/rfc/rfc1166.txt", + key="RFC 1166", + abstract={This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.}, + doi="10.17487/RFC1166", + } + +@misc{rfc1167, + author="V.G. Cerf", + title="{Thoughts on the National Research and Education Network}", + howpublished="RFC 1167 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1167", + pages="1--8", + year=1990, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1167.txt", + key="RFC 1167", + abstract={The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations.}, + doi="10.17487/RFC1167", + } + +@misc{rfc1168, + author="A. Westine and A.L. DeSchon and J. Postel and C.E. Ward", + title="{Intermail and Commercial Mail Relay services}", + howpublished="RFC 1168 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1168", + pages="1--18", + year=1990, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1168.txt", + key="RFC 1168", + abstract={This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard.}, + doi="10.17487/RFC1168", + } + +@misc{rfc1169, + author="V.G. Cerf and K.L. Mills", + title="{Explaining the role of GOSIP}", + howpublished="RFC 1169 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1169", + pages="1--15", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1169.txt", + key="RFC 1169", + abstract={This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard.}, + doi="10.17487/RFC1169", + } + +@misc{rfc1170, + author="R.B. Fougner", + title="{Public key standards and licenses}", + howpublished="RFC 1170 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1170", + pages="1--2", + year=1991, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1170.txt", + key="RFC 1170", + abstract={This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard.}, + doi="10.17487/RFC1170", + } + +@misc{rfc1171, + author="D. Perkins", + title="{Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links}", + howpublished="RFC 1171 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1171", + pages="1--51", + year=1990, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1331", +url="https://www.rfc-editor.org/rfc/rfc1171.txt", + key="RFC 1171", + abstract={This memo specifies the Point-to-Point Protocol (PPP) as a Draft Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.}, + doi="10.17487/RFC1171", + } + +@misc{rfc1172, + author="D. Perkins and R. Hobby", + title="{Point-to-Point Protocol (PPP) initial configuration options}", + howpublished="RFC 1172 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1172", + pages="1--40", + year=1990, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1331, 1332", +url="https://www.rfc-editor.org/rfc/rfc1172.txt", + key="RFC 1172", + abstract={This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.}, + doi="10.17487/RFC1172", + } + +@misc{rfc1173, + author="J. VanBokkelen", + title="{Responsibilities of host and network managers: A summary of the ``oral tradition'' of the Internet}", + howpublished="RFC 1173 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1173", + pages="1--5", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1173.txt", + key="RFC 1173", + abstract={This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the ``oral tradition'' of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB.}, + doi="10.17487/RFC1173", + } + +@misc{rfc1174, + author="V.G. Cerf", + title="{IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet ``connected'' status}", + howpublished="RFC 1174 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1174", + pages="1--9", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1174.txt", + key="RFC 1174", + abstract={This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.}, + doi="10.17487/RFC1174", + } + +@misc{rfc1175, + author="K.L. Bowers and T.L. LaQuey and J.K. Reynolds and K. Roubicek and M.K. Stahl and A. Yuan", + title="{FYI on where to start: A bibliography of internetworking information}", + howpublished="RFC 1175 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1175", + pages="1--43", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1175.txt", + key="RFC 1175", + abstract={This FYI RFC is a bibliography of information about TCP/IP internetworking, prepared by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 3.]}, + doi="10.17487/RFC1175", + } + +@misc{rfc1176, + author="M.R. Crispin", + title="{Interactive Mail Access Protocol: Version 2}", + howpublished="RFC 1176 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1176", + pages="1--30", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1176.txt", + key="RFC 1176", + abstract={This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server (``repository''). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.}, + keywords="IMAP2", + doi="10.17487/RFC1176", + } + +@misc{rfc1177, + author="G.S. Malkin and A.N. Marine and J.K. Reynolds", + title="{FYI on Questions and Answers: Answers to commonly asked ``new internet user'' questions}", + howpublished="RFC 1177 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1177", + pages="1--24", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1206", +url="https://www.rfc-editor.org/rfc/rfc1177.txt", + key="RFC 1177", + abstract={This FYI RFC is one of three FYI's called, ``Questions and Answers'' (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.]}, + doi="10.17487/RFC1177", + } + +@misc{rfc1178, + author="D. Libes", + title="{Choosing a name for your computer}", + howpublished="RFC 1178 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1178", + pages="1--8", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1178.txt", + key="RFC 1178", + abstract={This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 5.]}, + doi="10.17487/RFC1178", + } + +@misc{rfc1179, + author="L. McLaughlin", + title="{Line printer daemon protocol}", + howpublished="RFC 1179 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1179", + pages="1--14", + year=1990, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1179.txt", + key="RFC 1179", + abstract={This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.}, + keywords="LPDP", + doi="10.17487/RFC1179", + } + +@misc{rfc1180, + author="T.J. Socolofsky and C.J. Kale", + title="{TCP/IP tutorial}", + howpublished="RFC 1180 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1180", + pages="1--28", + year=1991, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1180.txt", + key="RFC 1180", + abstract={This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard.}, + doi="10.17487/RFC1180", + } + +@misc{rfc1181, + author="R. Blokzijl", + title="{RIPE Terms of Reference}", + howpublished="RFC 1181 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1181", + pages="1--2", + year=1990, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1181.txt", + key="RFC 1181", + abstract={This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard.}, + doi="10.17487/RFC1181", + } + +@misc{rfc1183, + author="C.F. Everhart and L.A. Mamakos and R. Ullmann and P.V. Mockapetris", + title="{New DNS RR Definitions}", + howpublished="RFC 1183 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1183", + pages="1--11", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5395, 5864, 6195, 6895", +url="https://www.rfc-editor.org/rfc/rfc1183.txt", + key="RFC 1183", + abstract={This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.}, + keywords="DNS-RR", + doi="10.17487/RFC1183", + } + +@misc{rfc1184, + author="D.A. Borman", + title="{Telnet Linemode Option}", + howpublished="RFC 1184 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1184", + pages="1--23", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1184.txt", + key="RFC 1184", + abstract={This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK]}, + keywords="TOPT-LINE", + doi="10.17487/RFC1184", + } + +@misc{rfc1185, + author="V. Jacobson and R.T. Braden and L. Zhang", + title="{TCP Extension for High-Speed Paths}", + howpublished="RFC 1185 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1185", + pages="1--21", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1323", +url="https://www.rfc-editor.org/rfc/rfc1185.txt", + key="RFC 1185", + abstract={This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.}, + doi="10.17487/RFC1185", + } + +@misc{rfc1186, + author="R.L. Rivest", + title="{MD4 Message Digest Algorithm}", + howpublished="RFC 1186 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1186", + pages="1--18", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1320", +url="https://www.rfc-editor.org/rfc/rfc1186.txt", + key="RFC 1186", + abstract={This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.}, + doi="10.17487/RFC1186", + } + +@misc{rfc1187, + author="M.T. Rose and K. McCloghrie and J.R. Davin", + title="{Bulk Table Retrieval with the SNMP}", + howpublished="RFC 1187 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1187", + pages="1--12", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1187.txt", + key="RFC 1187", + abstract={This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.}, + keywords="SNMP-BULK", + doi="10.17487/RFC1187", + } + +@misc{rfc1188, + author="D. Katz", + title="{Proposed Standard for the Transmission of IP Datagrams over FDDI Networks}", + howpublished="RFC 1188 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1188", + pages="1--11", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1188.txt", + key="RFC 1188", + abstract={This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC1188", + } + +@misc{rfc1189, + author="U.S. Warrier and L. Besaw and L. LaBarre and B.D. Handspicker", + title="{Common Management Information Services and Protocols for the Internet (CMOT and CMIP)}", + howpublished="RFC 1189 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1189", + pages="1--15", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1189.txt", + key="RFC 1189", + abstract={This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]}, + keywords="CMOT", + doi="10.17487/RFC1189", + } + +@misc{rfc1190, + author="C. Topolcic", + title="{Experimental Internet Stream Protocol: Version 2 (ST-II)}", + howpublished="RFC 1190 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1190", + pages="1--148", + year=1990, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1819", +url="https://www.rfc-editor.org/rfc/rfc1190.txt", + key="RFC 1190", + abstract={This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol.}, + doi="10.17487/RFC1190", + } + +@misc{rfc1191, + author="J.C. Mogul and S.E. Deering", + title="{Path MTU discovery}", + howpublished="RFC 1191 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1191", + pages="1--19", + year=1990, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1191.txt", + key="RFC 1191", + abstract={This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]}, + keywords="IP-MTU", + doi="10.17487/RFC1191", + } + +@misc{rfc1192, + author="B. Kahin", + title="{Commercialization of the Internet summary report}", + howpublished="RFC 1192 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1192", + pages="1--13", + year=1990, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1192.txt", + key="RFC 1192", + abstract={This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard.}, + doi="10.17487/RFC1192", + } + +@misc{rfc1193, + author="D. Ferrari", + title="{Client requirements for real-time communication services}", + howpublished="RFC 1193 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1193", + pages="1--24", + year=1990, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1193.txt", + key="RFC 1193", + abstract={This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard.}, + doi="10.17487/RFC1193", + } + +@misc{rfc1194, + author="D.P. Zimmerman", + title="{Finger User Information Protocol}", + howpublished="RFC 1194 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1194", + pages="1--12", + year=1990, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1196, 1288", +url="https://www.rfc-editor.org/rfc/rfc1194.txt", + key="RFC 1194", + abstract={This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK]}, + doi="10.17487/RFC1194", + } + +@misc{rfc1195, + author="R.W. Callon", + title="{Use of OSI IS-IS for routing in TCP/IP and dual environments}", + howpublished="RFC 1195 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1195", + pages="1--85", + year=1990, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1349, 5302, 5304", +url="https://www.rfc-editor.org/rfc/rfc1195.txt", + key="RFC 1195", + abstract={This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]}, + keywords="IS-IS", + doi="10.17487/RFC1195", + } + +@misc{rfc1196, + author="D.P. Zimmerman", + title="{Finger User Information Protocol}", + howpublished="RFC 1196 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1196", + pages="1--12", + year=1990, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1288", +url="https://www.rfc-editor.org/rfc/rfc1196.txt", + key="RFC 1196", + abstract={This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK]}, + doi="10.17487/RFC1196", + } + +@misc{rfc1197, + author="M. Sherman", + title="{Using ODA for translating multimedia information}", + howpublished="RFC 1197 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1197", + pages="1--2", + year=1990, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1197.txt", + key="RFC 1197", + abstract={The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard.}, + doi="10.17487/RFC1197", + } + +@misc{rfc1198, + author="R.W. Scheifler", + title="{FYI on the X window system}", + howpublished="RFC 1198 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1198", + pages="1--3", + year=1991, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1198.txt", + key="RFC 1198", + abstract={This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard.}, + doi="10.17487/RFC1198", + } + +@misc{rfc1199, + author="J. Reynolds", + title="{Request for Comments Summary Notes: 1100-1199}", + howpublished="RFC 1199 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1199", + pages="1--22", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1199.txt", + key="RFC 1199", + keywords="Summary, RFC", + doi="10.17487/RFC1199", + } + +@misc{rfc1200, + author="Defense Advanced Research Projects Agency and Internet Activities Board", + title="{IAB official protocol standards}", + howpublished="RFC 1200 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1200", + pages="1--31", + year=1991, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1250", +url="https://www.rfc-editor.org/rfc/rfc1200.txt", + key="RFC 1200", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC1200", + } + +@misc{rfc1201, + author="D. Provan", + title="{Transmitting IP traffic over ARCNET networks}", + howpublished="RFC 1201 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1201", + pages="1--7", + year=1991, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1201.txt", + key="RFC 1201", + abstract={This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the ``ARCNET Packet Header Definition Standard''. [STANDARDS-TRACK]}, + keywords="IP-ARC", + doi="10.17487/RFC1201", + } + +@misc{rfc1202, + author="M.T. Rose", + title="{Directory Assistance service}", + howpublished="RFC 1202 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1202", + pages="1--11", + year=1991, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1202.txt", + key="RFC 1202", + abstract={This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard.}, + keywords="DAS", + doi="10.17487/RFC1202", + } + +@misc{rfc1203, + author="J. Rice", + title="{Interactive Mail Access Protocol: Version 3}", + howpublished="RFC 1203 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1203", + pages="1--49", + year=1991, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1203.txt", + key="RFC 1203", + abstract={This RFC suggests a method for workstations to access mail dynamically from a mailbox server (``repository''). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.}, + keywords="IMAP3", + doi="10.17487/RFC1203", + } + +@misc{rfc1204, + author="S. Yeh and D. Lee", + title="{Message Posting Protocol (MPP)}", + howpublished="RFC 1204 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1204", + pages="1--6", + year=1991, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1204.txt", + key="RFC 1204", + abstract={This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.}, + keywords="MPP", + doi="10.17487/RFC1204", + } + +@misc{rfc1205, + author="P. Chmielewski", + title="{5250 Telnet interface}", + howpublished="RFC 1205 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1205", + pages="1--12", + year=1991, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2877", +url="https://www.rfc-editor.org/rfc/rfc1205.txt", + key="RFC 1205", + abstract={This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard.}, + doi="10.17487/RFC1205", + } + +@misc{rfc1206, + author="G.S. Malkin and A.N. Marine", + title="{FYI on Questions and Answers: Answers to commonly asked ``new Internet user'' questions}", + howpublished="RFC 1206 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1206", + pages="1--32", + year=1991, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1325", +url="https://www.rfc-editor.org/rfc/rfc1206.txt", + key="RFC 1206", + abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]}, + doi="10.17487/RFC1206", + } + +@misc{rfc1207, + author="G.S. Malkin and A.N. Marine and J.K. Reynolds", + title="{FYI on Questions and Answers: Answers to commonly asked ``experienced Internet user'' questions}", + howpublished="RFC 1207 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1207", + pages="1--15", + year=1991, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1207.txt", + key="RFC 1207", + abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard.}, + doi="10.17487/RFC1207", + } + +@misc{rfc1208, + author="O.J. Jacobsen and D.C. Lynch", + title="{A Glossary of Networking Terms}", + howpublished="RFC 1208 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1208", + pages="1--18", + year=1991, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1208.txt", + key="RFC 1208", + abstract={This RFC is a glossary adapted from ``The INTEROP Pocket Glossary of Networking Terms'' distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1208", + } + +@misc{rfc1209, + author="D. Piscitello and J. Lawrence", + title="{The Transmission of IP Datagrams over the SMDS Service}", + howpublished="RFC 1209 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1209", + pages="1--11", + year=1991, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1209.txt", + key="RFC 1209", + abstract={This memo defines a protocol for the transmission of IP and ARP packets over a Switched Multi-megabit Data Service Network configured as a logical IP subnetwork. [STANDARDS-TRACK]}, + keywords="IP-SMDS, Switched Multi-megabit Data Service", + doi="10.17487/RFC1209", + } + +@misc{rfc1210, + author="V.G. Cerf and P.T. Kirstein and B. Randell", + title="{Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990}", + howpublished="RFC 1210 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1210", + pages="1--36", + year=1991, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1210.txt", + key="RFC 1210", + abstract={This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1210", + } + +@misc{rfc1211, + author="A. Westine and J. Postel", + title="{Problems with the maintenance of large mailing lists}", + howpublished="RFC 1211 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1211", + pages="1--54", + year=1991, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1211.txt", + key="RFC 1211", + abstract={This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1211", + } + +@misc{rfc1212, + author="M.T. Rose and K. McCloghrie", + title="{Concise MIB definitions}", + howpublished="RFC 1212 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1212", + pages="1--19", + year=1991, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1212.txt", + key="RFC 1212", + abstract={This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. This memo defines a format for producing MIB modules. [STANDARDS-TRACK]}, + keywords="Concise-MIB", + doi="10.17487/RFC1212", + } + +@misc{rfc1213, + author="K. McCloghrie and M. Rose", + title="{Management Information Base for Network Management of TCP/IP-based internets: MIB-II}", + howpublished="RFC 1213 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1213", + pages="1--70", + year=1991, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2011, 2012, 2013", +url="https://www.rfc-editor.org/rfc/rfc1213.txt", + key="RFC 1213", + abstract={This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]}, + keywords="MIB-II", + doi="10.17487/RFC1213", + } + +@misc{rfc1214, + author="L. LaBarre", + title="{OSI internet management: Management Information Base}", + howpublished="RFC 1214 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1214", + pages="1--83", + year=1991, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1214.txt", + key="RFC 1214", + abstract={This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. [STANDARDS-TRACK]}, + keywords="OIM-MIB-II", + doi="10.17487/RFC1214", + } + +@misc{rfc1215, + author="M.T. Rose", + title="{Convention for defining traps for use with the SNMP}", + howpublished="RFC 1215 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1215", + pages="1--9", + year=1991, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1215.txt", + key="RFC 1215", + abstract={This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard.}, + keywords="SNMP-TRAPS", + doi="10.17487/RFC1215", + } + +@misc{rfc1216, + author="P. Richard and P. Kynikos", + title="{Gigabit network economics and paradigm shifts}", + howpublished="RFC 1216 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1216", + pages="1--4", + year=1991, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1216.txt", + key="RFC 1216", + abstract={This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]}, + doi="10.17487/RFC1216", + } + +@misc{rfc1217, + author="V.G. Cerf", + title="{Memo from the Consortium for Slow Commotion Research (CSCR)}", + howpublished="RFC 1217 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1217", + pages="1--5", + year=1991, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1217.txt", + key="RFC 1217", + abstract={This RFC is in response to RFC 1216, ``Gigabit Network Economics and Paradigm Shifts''. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1217", + } + +@misc{rfc1218, + author="North American Directory Forum", + title="{Naming scheme for c=US}", + howpublished="RFC 1218 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1218", + pages="1--23", + year=1991, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1255, 1417", +url="https://www.rfc-editor.org/rfc/rfc1218.txt", + key="RFC 1218", + abstract={This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1218", + } + +@misc{rfc1219, + author="P.F. Tsuchiya", + title="{On the assignment of subnet numbers}", + howpublished="RFC 1219 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1219", + pages="1--13", + year=1991, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1219.txt", + key="RFC 1219", + abstract={This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="SUBNETASGN", + doi="10.17487/RFC1219", + } + +@misc{rfc1220, + author="F. Baker", + title="{Point-to-Point Protocol extensions for bridging}", + howpublished="RFC 1220 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1220", + pages="1--18", + year=1991, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1638", +url="https://www.rfc-editor.org/rfc/rfc1220.txt", + key="RFC 1220", + abstract={This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]}, + doi="10.17487/RFC1220", + } + +@misc{rfc1221, + author="W. Edmond", + title="{Host Access Protocol (HAP) specification: Version 2}", + howpublished="RFC 1221 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1221", + pages="1--68", + year=1991, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1221.txt", + key="RFC 1221", + abstract={This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="HAP2", + doi="10.17487/RFC1221", + } + +@misc{rfc1222, + author="H.W. Braun and Y. Rekhter", + title="{Advancing the NSFNET routing architecture}", + howpublished="RFC 1222 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1222", + pages="1--6", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1222.txt", + key="RFC 1222", + abstract={This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1222", + } + +@misc{rfc1223, + author="J.M. Halpern", + title="{OSI CLNS and LLC1 protocols on Network Systems HYPERchannel}", + howpublished="RFC 1223 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1223", + pages="1--12", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1223.txt", + key="RFC 1223", + abstract={The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="OSI-HYPER", + doi="10.17487/RFC1223", + } + +@misc{rfc1224, + author="L. Steinberg", + title="{Techniques for managing asynchronously generated alerts}", + howpublished="RFC 1224 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1224", + pages="1--22", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1224.txt", + key="RFC 1224", + abstract={This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols. This memo specifies an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="ALERTS", + doi="10.17487/RFC1224", + } + +@misc{rfc1225, + author="M.T. Rose", + title="{Post Office Protocol: Version 3}", + howpublished="RFC 1225 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1225", + pages="1--16", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1460", +url="https://www.rfc-editor.org/rfc/rfc1225.txt", + key="RFC 1225", + abstract={This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]}, + doi="10.17487/RFC1225", + } + +@misc{rfc1226, + author="B. Kantor", + title="{Internet protocol encapsulation of AX.25 frames}", + howpublished="RFC 1226 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1226", + pages="1--2", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1226.txt", + key="RFC 1226", + abstract={This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="IP-AX.25", + doi="10.17487/RFC1226", + } + +@misc{rfc1227, + author="M.T. Rose", + title="{SNMP MUX protocol and MIB}", + howpublished="RFC 1227 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1227", + pages="1--13", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1227.txt", + key="RFC 1227", + abstract={This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="SNMP-MUX", + doi="10.17487/RFC1227", + } + +@misc{rfc1228, + author="G. Carpenter and B. Wijnen", + title="{SNMP-DPI: Simple Network Management Protocol Distributed Program Interface}", + howpublished="RFC 1228 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1228", + pages="1--50", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1592", +url="https://www.rfc-editor.org/rfc/rfc1228.txt", + key="RFC 1228", + abstract={This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1228", + } + +@misc{rfc1229, + author="K. McCloghrie", + title="{Extensions to the generic-interface MIB}", + howpublished="RFC 1229 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1229", + pages="1--16", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1573, updated by RFC 1239", +url="https://www.rfc-editor.org/rfc/rfc1229.txt", + key="RFC 1229", + abstract={This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS-TRACK]}, + doi="10.17487/RFC1229", + } + +@misc{rfc1230, + author="K. McCloghrie and R. Fox", + title="{IEEE 802.4 Token Bus MIB}", + howpublished="RFC 1230 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1230", + pages="1--23", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1239", +url="https://www.rfc-editor.org/rfc/rfc1230.txt", + key="RFC 1230", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]}, + keywords="802.4-MIP", + doi="10.17487/RFC1230", + } + +@misc{rfc1231, + author="K. McCloghrie and R. Fox and E. Decker", + title="{IEEE 802.5 Token Ring MIB}", + howpublished="RFC 1231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1231", + pages="1--23", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1743, 1748, updated by RFC 1239", +url="https://www.rfc-editor.org/rfc/rfc1231.txt", + key="RFC 1231", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]}, + doi="10.17487/RFC1231", + } + +@misc{rfc1232, + author="F. Baker and C.P. Kolb", + title="{Definitions of managed objects for the DS1 Interface type}", + howpublished="RFC 1232 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1232", + pages="1--28", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1406, updated by RFC 1239", +url="https://www.rfc-editor.org/rfc/rfc1232.txt", + key="RFC 1232", + doi="10.17487/RFC1232", + } + +@misc{rfc1233, + author="T.A. Cox and K. Tesink", + title="{Definitions of managed objects for the DS3 Interface type}", + howpublished="RFC 1233 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1233", + pages="1--23", + year=1991, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1407, updated by RFC 1239", +url="https://www.rfc-editor.org/rfc/rfc1233.txt", + key="RFC 1233", + abstract={This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]}, + doi="10.17487/RFC1233", + } + +@misc{rfc1234, + author="D. Provan", + title="{Tunneling IPX traffic through IP networks}", + howpublished="RFC 1234 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1234", + pages="1--6", + year=1991, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1234.txt", + key="RFC 1234", + abstract={This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]}, + keywords="IPX-IP", + doi="10.17487/RFC1234", + } + +@misc{rfc1235, + author="J. Ioannidis and G. Maguire", + title="{Coherent File Distribution Protocol}", + howpublished="RFC 1235 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1235", + pages="1--12", + year=1991, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1235.txt", + key="RFC 1235", + abstract={This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="CFDP", + doi="10.17487/RFC1235", + } + +@misc{rfc1236, + author="L. Morales and P. Hasse", + title="{IP to X.121 address mapping for DDN}", + howpublished="RFC 1236 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1236", + pages="1--7", + year=1991, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1236.txt", + key="RFC 1236", + abstract={This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="IP-X.121", + doi="10.17487/RFC1236", + } + +@misc{rfc1237, + author="R. Colella and E. Gardner and R. Callon", + title="{Guidelines for OSI NSAP Allocation in the Internet}", + howpublished="RFC 1237 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1237", + pages="1--48", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1629", +url="https://www.rfc-editor.org/rfc/rfc1237.txt", + key="RFC 1237", + abstract={This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]}, + doi="10.17487/RFC1237", + } + +@misc{rfc1238, + author="G. Satz", + title="{CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)}", + howpublished="RFC 1238 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1238", + pages="1--32", + year=1991, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1238.txt", + key="RFC 1238", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="CLNS-MIB", + doi="10.17487/RFC1238", + } + +@misc{rfc1239, + author="J.K. Reynolds", + title="{Reassignment of experimental MIBs to standard MIBs}", + howpublished="RFC 1239 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1239", + pages="1--2", + year=1991, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1239.txt", + key="RFC 1239", + abstract={This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]}, + keywords="STD-MIBs", + doi="10.17487/RFC1239", + } + +@misc{rfc1240, + author="C. Shue and W. Haggerty and K. Dobbins", + title="{OSI connectionless transport services on top of UDP: Version 1}", + howpublished="RFC 1240 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1240", + pages="1--8", + year=1991, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1240.txt", + key="RFC 1240", + abstract={This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]}, + keywords="OSI-UDP", + doi="10.17487/RFC1240", + } + +@misc{rfc1241, + author="R.A. Woodburn and D.L. Mills", + title="{Scheme for an internet encapsulation protocol: Version 1}", + howpublished="RFC 1241 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1241", + pages="1--17", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1241.txt", + key="RFC 1241", + abstract={This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="IN-ENCAP", + doi="10.17487/RFC1241", + } + +@misc{rfc1242, + author="S. Bradner", + title="{Benchmarking Terminology for Network Interconnection Devices}", + howpublished="RFC 1242 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1242", + pages="1--12", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6201", +url="https://www.rfc-editor.org/rfc/rfc1242.txt", + key="RFC 1242", + abstract={This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1242", + } + +@misc{rfc1243, + author="S. Waldbusser", + title="{AppleTalk Management Information Base}", + howpublished="RFC 1243 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1243", + pages="1--29", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1742", +url="https://www.rfc-editor.org/rfc/rfc1243.txt", + key="RFC 1243", + abstract={This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]}, + doi="10.17487/RFC1243", + } + +@misc{rfc1244, + author="J.P. Holbrook and J.K. Reynolds", + title="{Site Security Handbook}", + howpublished="RFC 1244 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1244", + pages="1--101", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2196", +url="https://www.rfc-editor.org/rfc/rfc1244.txt", + key="RFC 1244", + abstract={This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8]}, + doi="10.17487/RFC1244", + } + +@misc{rfc1245, + author="J. Moy", + title="{OSPF Protocol Analysis}", + howpublished="RFC 1245 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1245", + pages="1--12", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1245.txt", + key="RFC 1245", + abstract={This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard.}, + keywords="OSPF, SPF, routing, TOS, LSA, flooding", + doi="10.17487/RFC1245", + } + +@misc{rfc1246, + author="J. Moy", + title="{Experience with the OSPF Protocol}", + howpublished="RFC 1246 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1246", + pages="1--31", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1246.txt", + key="RFC 1246", + abstract={This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard.}, + keywords="OSPF, SPF, routing, MIB, experience, testing", + doi="10.17487/RFC1246", + } + +@misc{rfc1247, + author="J. Moy", + title="{OSPF Version 2}", + howpublished="RFC 1247 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1247", + pages="1--189", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1583, updated by RFC 1349", +url="https://www.rfc-editor.org/rfc/rfc1247.txt", + key="RFC 1247", + abstract={This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]}, + keywords="equal-cost, multipath, link state, LSA", + doi="10.17487/RFC1247", + } + +@misc{rfc1248, + author="F. Baker and R. Coltun", + title="{OSPF Version 2 Management Information Base}", + howpublished="RFC 1248 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1248", + pages="1--42", + year=1991, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1252, updated by RFC 1349", +url="https://www.rfc-editor.org/rfc/rfc1248.txt", + key="RFC 1248", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]}, + keywords="OSPF, SPF, MIB, routing, network management", + doi="10.17487/RFC1248", + } + +@misc{rfc1249, + author="T. Howes and M. Smith and B. Beecher", + title="{DIXIE Protocol Specification}", + howpublished="RFC 1249 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1249", + pages="1--10", + year=1991, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1249.txt", + key="RFC 1249", + abstract={This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard.}, + keywords="DIXIE, DIXIE, protocol, directory services, X.500, DAP", + doi="10.17487/RFC1249", + } + +@misc{rfc1250, + author="J. Postel", + title="{IAB Official Protocol Standards}", + howpublished="RFC 1250 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1250", + pages="1--28", + year=1991, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2200, 1280", +url="https://www.rfc-editor.org/rfc/rfc1250.txt", + key="RFC 1250", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="standards, protocol, IAB", + doi="10.17487/RFC1250", + } + +@misc{rfc1251, + author="G. Malkin", + title="{Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members}", + howpublished="RFC 1251 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1251", + pages="1--26", + year=1991, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1336", +url="https://www.rfc-editor.org/rfc/rfc1251.txt", + key="RFC 1251", + abstract={This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]}, + keywords="IESG, IRSG, IAB", + doi="10.17487/RFC1251", + } + +@misc{rfc1252, + author="F. Baker and R. Coltun", + title="{OSPF Version 2 Management Information Base}", + howpublished="RFC 1252 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1252", + pages="1--42", + year=1991, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1253", +url="https://www.rfc-editor.org/rfc/rfc1252.txt", + key="RFC 1252", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]}, + keywords="OSPF, SPF, MIB, routing, network management", + doi="10.17487/RFC1252", + } + +@misc{rfc1253, + author="F. Baker and R. Coltun", + title="{OSPF Version 2 Management Information Base}", + howpublished="RFC 1253 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1253", + pages="1--42", + year=1991, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1850", +url="https://www.rfc-editor.org/rfc/rfc1253.txt", + key="RFC 1253", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]}, + doi="10.17487/RFC1253", + } + +@misc{rfc1254, + author="A. Mankin and K. Ramakrishnan", + title="{Gateway Congestion Control Survey}", + howpublished="RFC 1254 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1254", + pages="1--25", + year=1991, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1254.txt", + key="RFC 1254", + abstract={The purpose of this paper is to present a review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing.}, + keywords="gateway, congestion, SQ, source quench, fiar queueing, random drop", + doi="10.17487/RFC1254", + } + +@misc{rfc1255, + author="The North American Directory Forum", + title="{A Naming Scheme for c=US}", + howpublished="RFC 1255 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1255", + pages="1--25", + year=1991, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1417", +url="https://www.rfc-editor.org/rfc/rfc1255.txt", + key="RFC 1255", + abstract={This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="naming, NADF, X.500, directory services, c=us", + doi="10.17487/RFC1255", + } + +@misc{rfc1256, + author="S. {Deering (Ed.)}", + title="{ICMP Router Discovery Messages}", + howpublished="RFC 1256 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1256", + pages="1--19", + year=1991, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1256.txt", + key="RFC 1256", + abstract={This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK]}, + keywords="ICMP-ROUT, ICMP, router, gateway, discovery, standard, protocol", + doi="10.17487/RFC1256", + } + +@misc{rfc1257, + author="C. Partridge", + title="{Isochronous applications do not require jitter-controlled networks}", + howpublished="RFC 1257 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1257", + pages="1--5", + year=1991, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1257.txt", + key="RFC 1257", + abstract={This memo argues that jitter control is not required for networks to support isochronous applications. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1257", + } + +@misc{rfc1258, + author="B. Kantor", + title="{BSD Rlogin}", + howpublished="RFC 1258 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1258", + pages="1--5", + year=1991, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1282", +url="https://www.rfc-editor.org/rfc/rfc1258.txt", + key="RFC 1258", + abstract={The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1258", + } + +@misc{rfc1259, + author="M. Kapor", + title="{Building the open road: The NREN as test-bed for the national public network}", + howpublished="RFC 1259 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1259", + pages="1--23", + year=1991, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1259.txt", + key="RFC 1259", + abstract={This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="NREN, test-bed, network policy", + doi="10.17487/RFC1259", + } + +@misc{rfc1261, + author="S. Williamson and L. Nobile", + title="{Transition of Nic Services}", + howpublished="RFC 1261 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1261", + pages="1--3", + year=1991, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1261.txt", + key="RFC 1261", + abstract={This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="NIC, transition", + doi="10.17487/RFC1261", + } + +@misc{rfc1262, + author="V.G. Cerf", + title="{Guidelines for Internet Measurement Activities}", + howpublished="RFC 1262 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1262", + pages="1--3", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1262.txt", + key="RFC 1262", + abstract={This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1262", + } + +@misc{rfc1263, + author="S. O'Malley and L.L. Peterson", + title="{TCP Extensions Considered Harmful}", + howpublished="RFC 1263 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1263", + pages="1--19", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1263.txt", + key="RFC 1263", + abstract={This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1263", + } + +@misc{rfc1264, + author="R.M. Hinden", + title="{Internet Engineering Task Force Internet Routing Protocol Standardization Criteria}", + howpublished="RFC 1264 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1264", + pages="1--8", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4794", +url="https://www.rfc-editor.org/rfc/rfc1264.txt", + key="RFC 1264", + abstract={This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.}, + doi="10.17487/RFC1264", + } + +@misc{rfc1265, + author="Y. Rekhter", + title="{BGP Protocol Analysis}", + howpublished="RFC 1265 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1265", + pages="1--8", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1265.txt", + key="RFC 1265", + abstract={This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1265", + } + +@misc{rfc1266, + author="Y. Rekhter", + title="{Experience with the BGP Protocol}", + howpublished="RFC 1266 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1266", + pages="1--9", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1266.txt", + key="RFC 1266", + abstract={The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1266", + } + +@misc{rfc1267, + author="K. Lougheed and Y. Rekhter", + title="{Border Gateway Protocol 3 (BGP-3)}", + howpublished="RFC 1267 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1267", + pages="1--35", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1267.txt", + key="RFC 1267", + abstract={This memo, together with its companion document, ``Application of the Border Gateway Protocol in the Internet'', define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]}, + keywords="BGP3", + doi="10.17487/RFC1267", + } + +@misc{rfc1268, + author="Y. Rekhter and P. Gross", + title="{Application of the Border Gateway Protocol in the Internet}", + howpublished="RFC 1268 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1268", + pages="1--13", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1655", +url="https://www.rfc-editor.org/rfc/rfc1268.txt", + key="RFC 1268", + abstract={This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]}, + keywords="BGP3", + doi="10.17487/RFC1268", + } + +@misc{rfc1269, + author="S. Willis and J.W. Burruss", + title="{Definitions of Managed Objects for the Border Gateway Protocol: Version 3}", + howpublished="RFC 1269 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1269", + pages="1--13", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4273", +url="https://www.rfc-editor.org/rfc/rfc1269.txt", + key="RFC 1269", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK]}, + keywords="BGP-MIB", + doi="10.17487/RFC1269", + } + +@misc{rfc1270, + author="F. Kastenholz", + title="{SNMP Communications Services}", + howpublished="RFC 1270 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1270", + pages="1--11", + year=1991, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1270.txt", + key="RFC 1270", + abstract={This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1270", + } + +@misc{rfc1271, + author="S. Waldbusser", + title="{Remote Network Monitoring Management Information Base}", + howpublished="RFC 1271 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1271", + pages="1--81", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1757, updated by RFC 1513", +url="https://www.rfc-editor.org/rfc/rfc1271.txt", + key="RFC 1271", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]}, + doi="10.17487/RFC1271", + } + +@misc{rfc1272, + author="C. Mills and D. Hirsh and G.R. Ruth", + title="{Internet Accounting: Background}", + howpublished="RFC 1272 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1272", + pages="1--19", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1272.txt", + key="RFC 1272", + abstract={This document provides background information for the ``Internet Accounting Architecture''. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1272", + } + +@misc{rfc1273, + author="M.F. Schwartz", + title="{Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations}", + howpublished="RFC 1273 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1273", + pages="1--8", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1273.txt", + key="RFC 1273", + abstract={This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1273", + } + +@misc{rfc1274, + author="P. Barker and S. Kille", + title="{The COSINE and Internet X.500 Schema}", + howpublished="RFC 1274 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1274", + pages="1--60", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4524", +url="https://www.rfc-editor.org/rfc/rfc1274.txt", + key="RFC 1274", + abstract={This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK]}, + keywords="Naming", + doi="10.17487/RFC1274", + } + +@misc{rfc1275, + author="S.E. Hardcastle-Kille", + title="{Replication Requirements to provide an Internet Directory using X.500}", + howpublished="RFC 1275 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1275", + pages="1--3", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1275.txt", + key="RFC 1275", + abstract={This RFC considers certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services [CCI88]. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1275", + } + +@misc{rfc1276, + author="S.E. Hardcastle-Kille", + title="{Replication and Distributed Operations extensions to provide an Internet Directory using X.500}", + howpublished="RFC 1276 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1276", + pages="1--17", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1276.txt", + key="RFC 1276", + abstract={Some requirements on extensions to X.500 are described in the RFC[HK91b], in order to build an Internet Directory using X.500(1988). This document specifies a set of solutions to the problems raised. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC1276", + } + +@misc{rfc1277, + author="S.E. Hardcastle-Kille", + title="{Encoding Network Addresses to Support Operation over Non-OSI Lower Layers}", + howpublished="RFC 1277 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1277", + pages="1--12", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1277.txt", + key="RFC 1277", + abstract={This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK]}, + keywords="address ISO OSI", + doi="10.17487/RFC1277", + } + +@misc{rfc1278, + author="S.E. Hardcastle-Kille", + title="{A string encoding of Presentation Address}", + howpublished="RFC 1278 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1278", + pages="1--7", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1278.txt", + key="RFC 1278", + abstract={There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="OSI, ASN.1", + doi="10.17487/RFC1278", + } + +@misc{rfc1279, + author="S.E. Hardcastle-Kille", + title="{X.500 and Domains}", + howpublished="RFC 1279 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1279", + pages="1--15", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1279.txt", + key="RFC 1279", + abstract={This RFC considers X.500 in relation to Internet and UK Domains. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="Domain, Name, naming", + doi="10.17487/RFC1279", + } + +@misc{rfc1280, + author="J. Postel", + title="{IAB Official Protocol Standards}", + howpublished="RFC 1280 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1280", + pages="1--32", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1360", +url="https://www.rfc-editor.org/rfc/rfc1280.txt", + key="RFC 1280", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1280", + } + +@misc{rfc1281, + author="R. Pethia and S. Crocker and B. Fraser", + title="{Guidelines for the Secure Operation of the Internet}", + howpublished="RFC 1281 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1281", + pages="1--10", + year=1991, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1281.txt", + key="RFC 1281", + abstract={The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="security, privacy, protection, guideline", + doi="10.17487/RFC1281", + } + +@misc{rfc1282, + author="B. Kantor", + title="{BSD Rlogin}", + howpublished="RFC 1282 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1282", + pages="1--5", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1282.txt", + key="RFC 1282", + abstract={This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="BSD Login, Unix, remote-login, remote-logon", + doi="10.17487/RFC1282", + } + +@misc{rfc1283, + author="M. Rose", + title="{SNMP over OSI}", + howpublished="RFC 1283 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1283", + pages="1--8", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1418", +url="https://www.rfc-editor.org/rfc/rfc1283.txt", + key="RFC 1283", + abstract={This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard.}, + keywords="ISO, Management, MIB", + doi="10.17487/RFC1283", + } + +@misc{rfc1284, + author="J. {Cook (Ed.)}", + title="{Definitions of Managed Objects for the Ethernet-like Interface Types}", + howpublished="RFC 1284 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1284", + pages="1--21", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1398", +url="https://www.rfc-editor.org/rfc/rfc1284.txt", + key="RFC 1284", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]}, + keywords="SNMP, MIB, Management", + doi="10.17487/RFC1284", + } + +@misc{rfc1285, + author="J. Case", + title="{FDDI Management Information Base}", + howpublished="RFC 1285 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1285", + pages="1--46", + year=1992, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1512", +url="https://www.rfc-editor.org/rfc/rfc1285.txt", + key="RFC 1285", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK]}, + keywords="FDDI-MIB, standard, standards, MIB, SNMP", + doi="10.17487/RFC1285", + } + +@misc{rfc1286, + author="E. Decker and P. Langille and A. Rijsinghani and K. McCloghrie", + title="{Definitions of Managed Objects for Bridges}", + howpublished="RFC 1286 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1286", + pages="1--40", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1493, 1525", +url="https://www.rfc-editor.org/rfc/rfc1286.txt", + key="RFC 1286", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]}, + keywords="SNMP, MIB, standard, standards", + doi="10.17487/RFC1286", + } + +@misc{rfc1287, + author="D. Clark and L. Chapin and V. Cerf and R. Braden and R. Hobby", + title="{Towards the Future Internet Architecture}", + howpublished="RFC 1287 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1287", + pages="1--29", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1287.txt", + key="RFC 1287", + abstract={This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1287", + } + +@misc{rfc1288, + author="D. Zimmerman", + title="{The Finger User Information Protocol}", + howpublished="RFC 1288 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1288", + pages="1--12", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1288.txt", + key="RFC 1288", + abstract={This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK]}, + keywords="FINGER", + doi="10.17487/RFC1288", + } + +@misc{rfc1289, + author="J. Saperia", + title="{DECnet Phase IV MIB Extensions}", + howpublished="RFC 1289 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1289", + pages="1--64", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1559", +url="https://www.rfc-editor.org/rfc/rfc1289.txt", + key="RFC 1289", + abstract={This memo is an extension to the SNMP MIB. This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. [STANDARDS-TRACK]}, + keywords="SNMP, Management, protocol, standard, standards", + doi="10.17487/RFC1289", + } + +@misc{rfc1290, + author="J. Martin", + title="{There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places}", + howpublished="RFC 1290 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1290", + pages="1--27", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1402", +url="https://www.rfc-editor.org/rfc/rfc1290.txt", + key="RFC 1290", + abstract={This paper will present some of the ``gold nuggets'' of information and file repositories on the network that could be of use to end users. This RFC provides information for the Internet community. It does not specify an Internet standard.}, + keywords="SIGUCCS, User Services, Help, Internet", + doi="10.17487/RFC1290", + } + +@misc{rfc1291, + author="V. Aggarwal", + title="{Mid-Level Networks Potential Technical Services}", + howpublished="RFC 1291 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1291", + pages="1--10", + year=1991, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1291.txt", + key="RFC 1291", + abstract={This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. This RFC provides information for the Internet community. It does not specify an Internet standard.}, + keywords="statistics, connectivity, management", + doi="10.17487/RFC1291", + } + +@misc{rfc1292, + author="R. Lang and R. Wright", + title="{A Catalog of Available X.500 Implementations}", + howpublished="RFC 1292 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1292", + pages="1--103", + year=1992, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1632", +url="https://www.rfc-editor.org/rfc/rfc1292.txt", + key="RFC 1292", + abstract={The goal of this document is to provide information regarding the availability and capability of implementations of X.500. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1292", + } + +@misc{rfc1293, + author="T. Bradley and C. Brown", + title="{Inverse Address Resolution Protocol}", + howpublished="RFC 1293 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1293", + pages="1--6", + year=1992, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2390", +url="https://www.rfc-editor.org/rfc/rfc1293.txt", + key="RFC 1293", + abstract={This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]}, + keywords="standard, standards, ARP, DLCI", + doi="10.17487/RFC1293", + } + +@misc{rfc1294, + author="T. Bradley and C. Brown and A. Malis", + title="{Multiprotocol Interconnect over Frame Relay}", + howpublished="RFC 1294 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1294", + pages="1--28", + year=1992, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1490, 2427", +url="https://www.rfc-editor.org/rfc/rfc1294.txt", + key="RFC 1294", + abstract={This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]}, + keywords="standard, standards", + doi="10.17487/RFC1294", + } + +@misc{rfc1295, + author="The North American Directory Forum", + title="{User Bill of Rights for entries and listings in the Public Directory}", + howpublished="RFC 1295 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1295", + pages="1--2", + year=1992, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1417", +url="https://www.rfc-editor.org/rfc/rfc1295.txt", + key="RFC 1295", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="NADF-265, NADF, X.500", + doi="10.17487/RFC1295", + } + +@misc{rfc1296, + author="M. Lottor", + title="{Internet Growth (1981-1991)}", + howpublished="RFC 1296 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1296", + pages="1--9", + year=1992, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1296.txt", + key="RFC 1296", + abstract={This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]}, + keywords="statistics, ZONE", + doi="10.17487/RFC1296", + } + +@misc{rfc1297, + author="D. Johnson", + title="{NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist (``NOC TT REQUIREMENTS'')}", + howpublished="RFC 1297 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1297", + pages="1--12", + year=1992, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1297.txt", + key="RFC 1297", + abstract={This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="problems, tracking, operations, NOC", + doi="10.17487/RFC1297", + } + +@misc{rfc1298, + author="R. Wormley and S. Bostock", + title="{SNMP over IPX}", + howpublished="RFC 1298 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1298", + pages="1--5", + year=1992, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1420", +url="https://www.rfc-editor.org/rfc/rfc1298.txt", + key="RFC 1298", + abstract={This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1298", + } + +@misc{rfc1299, + author="M. Kennedy", + title="{Summary of 1200-1299}", + howpublished="RFC 1299 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1299", + pages="1--20", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1299.txt", + key="RFC 1299", + keywords="Index", + doi="10.17487/RFC1299", + } + +@misc{rfc1300, + author="S. Greenfield", + title="{Remembrances of Things Past}", + howpublished="RFC 1300 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1300", + pages="1--4", + year=1992, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1300.txt", + key="RFC 1300", + abstract={Poem. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="poem", + doi="10.17487/RFC1300", + } + +@misc{rfc1301, + author="S. Armstrong and A. Freier and K. Marzullo", + title="{Multicast Transport Protocol}", + howpublished="RFC 1301 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1301", + pages="1--38", + year=1992, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1301.txt", + key="RFC 1301", + abstract={This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="MTP, MTP, reliable transport, multicast, broadcast, collaboration, networking", + doi="10.17487/RFC1301", + } + +@misc{rfc1302, + author="D. Sitzler and P. Smith and A. Marine", + title="{Building a Network Information Services Infrastructure}", + howpublished="RFC 1302 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1302", + pages="1--13", + year=1992, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1302.txt", + key="RFC 1302", + abstract={This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="NISI, NIC, User Services", + doi="10.17487/RFC1302", + } + +@misc{rfc1303, + author="K. McCloghrie and M. Rose", + title="{A Convention for Describing SNMP-based Agents}", + howpublished="RFC 1303 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1303", + pages="1--12", + year=1992, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1303.txt", + key="RFC 1303", + abstract={This memo suggests a straight-forward approach towards describing SNMP- based agents. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="SNMP, MIB, Network Management,", + doi="10.17487/RFC1303", + } + +@misc{rfc1304, + author="T. {Cox (Ed.)} and K. {Tesink (Ed.)}", + title="{Definitions of Managed Objects for the SIP Interface Type}", + howpublished="RFC 1304 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1304", + pages="1--25", + year=1992, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1694", +url="https://www.rfc-editor.org/rfc/rfc1304.txt", + key="RFC 1304", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SIP (SMDS Interface Protocol) objects. [STANDARDS-TRACK]}, + keywords="Standard, MIB, Network Management, SMDS", + doi="10.17487/RFC1304", + } + +@misc{rfc1305, + author="D. Mills", + title="{Network Time Protocol (Version 3) Specification, Implementation and Analysis}", + howpublished="RFC 1305 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1305", + pages="1--109", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5905", +url="https://www.rfc-editor.org/rfc/rfc1305.txt", + key="RFC 1305", + abstract={This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]}, + keywords="NTPV3, NTP", + doi="10.17487/RFC1305", + } + +@misc{rfc1306, + author="A. Nicholson and J. Young", + title="{Experiences Supporting By-Request Circuit-Switched T3 Networks}", + howpublished="RFC 1306 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1306", + pages="1--10", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1306.txt", + key="RFC 1306", + abstract={This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. This RFC provides information for the Internet community. It does not specify an Internet standard.}, + keywords="WAN, Wide Area Net, FDDI", + doi="10.17487/RFC1306", + } + +@misc{rfc1307, + author="J. Young and A. Nicholson", + title="{Dynamically Switched Link Control Protocol}", + howpublished="RFC 1307 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1307", + pages="1--13", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1307.txt", + key="RFC 1307", + abstract={This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DSLCP, Experimental Protocol, T3, FDDI", + doi="10.17487/RFC1307", + } + +@misc{rfc1308, + author="C. Weider and J. Reynolds", + title="{Executive Introduction to Directory Services Using the X.500 Protocol}", + howpublished="RFC 1308 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1308", + pages="1--4", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1308.txt", + key="RFC 1308", + abstract={This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1308", + } + +@misc{rfc1309, + author="C. Weider and J. Reynolds and S. Heker", + title="{Technical Overview of Directory Services Using the X.500 Protocol}", + howpublished="RFC 1309 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1309", + pages="1--16", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1309.txt", + key="RFC 1309", + abstract={This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1309", + } + +@misc{rfc1310, + author="L. Chapin", + title="{The Internet Standards Process}", + howpublished="RFC 1310 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1310", + pages="1--23", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1602", +url="https://www.rfc-editor.org/rfc/rfc1310.txt", + key="RFC 1310", + abstract={This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]}, + doi="10.17487/RFC1310", + } + +@misc{rfc1311, + author="J. Postel", + title="{Introduction to the STD Notes}", + howpublished="RFC 1311 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1311", + pages="1--5", + year=1992, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1311.txt", + key="RFC 1311", + abstract={The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK]}, + keywords="new, IAB", + doi="10.17487/RFC1311", + } + +@misc{rfc1312, + author="R. Nelson and G. Arnold", + title="{Message Send Protocol 2}", + howpublished="RFC 1312 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1312", + pages="1--8", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1312.txt", + key="RFC 1312", + abstract={The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MSP2, MSP, talk", + doi="10.17487/RFC1312", + } + +@misc{rfc1313, + author="C. Partridge", + title="{Today's Programming for KRFC AM 1313 Internet Talk Radio}", + howpublished="RFC 1313 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1313", + pages="1--3", + year=1992, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1313.txt", + key="RFC 1313", + abstract={Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1313", + } + +@misc{rfc1314, + author="A. Katz and D. Cohen", + title="{A File Format for the Exchange of Images in the Internet}", + howpublished="RFC 1314 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1314", + pages="1--23", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1314.txt", + key="RFC 1314", + abstract={This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK]}, + keywords="NETFAX, netfax, TIFF, facsimile", + doi="10.17487/RFC1314", + } + +@misc{rfc1315, + author="C. Brown and F. Baker and C. Carvalho", + title="{Management Information Base for Frame Relay DTEs}", + howpublished="RFC 1315 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1315", + pages="1--19", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2115", +url="https://www.rfc-editor.org/rfc/rfc1315.txt", + key="RFC 1315", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Frame Relay. [STANDARDS-TRACK]}, + keywords="MIB", + doi="10.17487/RFC1315", + } + +@misc{rfc1316, + author="B. Stewart", + title="{Definitions of Managed Objects for Character Stream Devices}", + howpublished="RFC 1316 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1316", + pages="1--17", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1658", +url="https://www.rfc-editor.org/rfc/rfc1316.txt", + key="RFC 1316", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK]}, + keywords="MIB", + doi="10.17487/RFC1316", + } + +@misc{rfc1317, + author="B. Stewart", + title="{Definitions of Managed Objects for RS-232-like Hardware Devices}", + howpublished="RFC 1317 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1317", + pages="1--17", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1659", +url="https://www.rfc-editor.org/rfc/rfc1317.txt", + key="RFC 1317", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]}, + keywords="MIB", + doi="10.17487/RFC1317", + } + +@misc{rfc1318, + author="B. Stewart", + title="{Definitions of Managed Objects for Parallel-printer-like Hardware Devices}", + howpublished="RFC 1318 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1318", + pages="1--11", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1660", +url="https://www.rfc-editor.org/rfc/rfc1318.txt", + key="RFC 1318", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK]}, + keywords="MIB", + doi="10.17487/RFC1318", + } + +@misc{rfc1319, + author="B. Kaliski", + title="{The MD2 Message-Digest Algorithm}", + howpublished="RFC 1319 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1319", + pages="1--17", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6149", +url="https://www.rfc-editor.org/rfc/rfc1319.txt", + key="RFC 1319", + abstract={This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit ``fingerprint'' or ``message digest'' of the input. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="security, encryption, signature", + doi="10.17487/RFC1319", + } + +@misc{rfc1320, + author="R. Rivest", + title="{The MD4 Message-Digest Algorithm}", + howpublished="RFC 1320 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1320", + pages="1--20", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6150", +url="https://www.rfc-editor.org/rfc/rfc1320.txt", + key="RFC 1320", + abstract={This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit ``fingerprint'' or ``message digest'' of the input. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="MD4, security, encryption, signature", + doi="10.17487/RFC1320", + } + +@misc{rfc1321, + author="R. Rivest", + title="{The MD5 Message-Digest Algorithm}", + howpublished="RFC 1321 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1321", + pages="1--21", + year=1992, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6151", +url="https://www.rfc-editor.org/rfc/rfc1321.txt", + key="RFC 1321", + abstract={This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit ``fingerprint'' or ``message digest'' of the input. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="security, signature, eneryption", + doi="10.17487/RFC1321", + } + +@misc{rfc1322, + author="D. Estrin and Y. Rekhter and S. Hotz", + title="{A Unified Approach to Inter-Domain Routing}", + howpublished="RFC 1322 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1322", + pages="1--38", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1322.txt", + key="RFC 1322", + abstract={This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="path, vector, routing, source, demand, routing", + doi="10.17487/RFC1322", + } + +@misc{rfc1323, + author="V. Jacobson and R. Braden and D. Borman", + title="{TCP Extensions for High Performance}", + howpublished="RFC 1323 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1323", + pages="1--37", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7323", +url="https://www.rfc-editor.org/rfc/rfc1323.txt", + key="RFC 1323", + abstract={This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]}, + keywords="TCP-EXT, options, PAWS, window, scale, window", + doi="10.17487/RFC1323", + } + +@misc{rfc1324, + author="D. Reed", + title="{A Discussion on Computer Network Conferencing}", + howpublished="RFC 1324 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1324", + pages="1--11", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1324.txt", + key="RFC 1324", + abstract={This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="talk, real time, chat", + doi="10.17487/RFC1324", + } + +@misc{rfc1325, + author="G. Malkin and A. Marine", + title="{FYI on Questions and Answers Answers to Commonly asked ``New Internet User'' Questions}", + howpublished="RFC 1325 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1325", + pages="1--42", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1594", +url="https://www.rfc-editor.org/rfc/rfc1325.txt", + key="RFC 1325", + abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="documentation, help, information", + doi="10.17487/RFC1325", + } + +@misc{rfc1326, + author="P. Tsuchiya", + title="{Mutual Encapsulation Considered Dangerous}", + howpublished="RFC 1326 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1326", + pages="1--5", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1326.txt", + key="RFC 1326", + abstract={This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="protocol, layering, wrapping", + doi="10.17487/RFC1326", + } + +@misc{rfc1327, + author="S. Hardcastle-Kille", + title="{Mapping between X.400(1988) / ISO 10021 and RFC 822}", + howpublished="RFC 1327 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1327", + pages="1--113", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2156, updated by RFC 1495", +url="https://www.rfc-editor.org/rfc/rfc1327.txt", + key="RFC 1327", + abstract={This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK]}, + keywords="Electronic-mail,Message handling systems", + doi="10.17487/RFC1327", + } + +@misc{rfc1328, + author="S. Hardcastle-Kille", + title="{X.400 1988 to 1984 downgrading}", + howpublished="RFC 1328 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1328", + pages="1--5", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1328.txt", + key="RFC 1328", + abstract={This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe. [STANDARDS-TRACK]}, + keywords="Electronic-mail, message handling systems,mail", + doi="10.17487/RFC1328", + } + +@misc{rfc1329, + author="P. Kuehn", + title="{Thoughts on Address Resolution for Dual MAC FDDI Networks}", + howpublished="RFC 1329 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1329", + pages="1--28", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc1329.txt", + key="RFC 1329", + abstract={In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1329", + } + +@misc{rfc1330, + author="ESCC X.500/X.400 Task Force and ESnet Site Coordinating Comittee (ESCC) and Energy Sciences Network (ESnet)", + title="{Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community}", + howpublished="RFC 1330 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1330", + pages="1--87", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1330.txt", + key="RFC 1330", + abstract={This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1330", + } + +@misc{rfc1331, + author="W. Simpson", + title="{The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links}", + howpublished="RFC 1331 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1331", + pages="1--69", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1548", +url="https://www.rfc-editor.org/rfc/rfc1331.txt", + key="RFC 1331", + abstract={This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]}, + keywords="serial line, IP over serial, dial-up", + doi="10.17487/RFC1331", + } + +@misc{rfc1332, + author="G. McGregor", + title="{The PPP Internet Protocol Control Protocol (IPCP)}", + howpublished="RFC 1332 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1332", + pages="1--14", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3241", +url="https://www.rfc-editor.org/rfc/rfc1332.txt", + key="RFC 1332", + abstract={The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]}, + keywords="PPP-IPCP, serial line, IP over serial, dial-up", + doi="10.17487/RFC1332", + } + +@misc{rfc1333, + author="W. Simpson", + title="{PPP Link Quality Monitoring}", + howpublished="RFC 1333 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1333", + pages="1--17", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1989", +url="https://www.rfc-editor.org/rfc/rfc1333.txt", + key="RFC 1333", + abstract={The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. [STANDARDS-TRACK]}, + keywords="serial line, IP over serial, dial-up", + doi="10.17487/RFC1333", + } + +@misc{rfc1334, + author="B. Lloyd and W. Simpson", + title="{PPP Authentication Protocols}", + howpublished="RFC 1334 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1334", + pages="1--16", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1994", +url="https://www.rfc-editor.org/rfc/rfc1334.txt", + key="RFC 1334", + abstract={This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK]}, + keywords="point, serial, line, dial-up", + doi="10.17487/RFC1334", + } + +@misc{rfc1335, + author="Z. Wang and J. Crowcroft", + title="{A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion}", + howpublished="RFC 1335 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1335", + pages="1--7", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1335.txt", + key="RFC 1335", + abstract={This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an ``idea'' paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="internet, protocol, IP", + doi="10.17487/RFC1335", + } + +@misc{rfc1336, + author="G. Malkin", + title="{Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members}", + howpublished="RFC 1336 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1336", + pages="1--33", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1336.txt", + key="RFC 1336", + abstract={This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify any standard.}, + keywords="Almquist, Braden, Braun, Callon, Cerf, Chiappa, Chapin, Clark, Crocker, Davin, Estrin, Hobby, Huitema, Huizer, Kent, Lauck, Leiner, Lynch, Piscitello, Postel, Reynolds, Schwartz, Stockman, Vaudreuil", + doi="10.17487/RFC1336", + } + +@misc{rfc1337, + author="R. Braden", + title="{TIME-WAIT Assassination Hazards in TCP}", + howpublished="RFC 1337 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1337", + pages="1--11", + year=1992, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1337.txt", + key="RFC 1337", + abstract={This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="TCP protocol, protocol state, graceful close, reset", + doi="10.17487/RFC1337", + } + +@misc{rfc1338, + author="V. Fuller and T. Li and J. Yu and K. Varadhan", + title="{Supernetting: an Address Assignment and Aggregation Strategy}", + howpublished="RFC 1338 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1338", + pages="1--20", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1519", +url="https://www.rfc-editor.org/rfc/rfc1338.txt", + key="RFC 1338", + abstract={This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="internet address, routing", + doi="10.17487/RFC1338", + } + +@misc{rfc1339, + author="S. Dorner and P. Resnick", + title="{Remote Mail Checking Protocol}", + howpublished="RFC 1339 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1339", + pages="1--6", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1339.txt", + key="RFC 1339", + abstract={This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user. This memo defines an Experimental Protocol for the Internet community.}, + keywords="RMCP, email, remote mail", + doi="10.17487/RFC1339", + } + +@misc{rfc1340, + author="J. Reynolds and J. Postel", + title="{Assigned Numbers}", + howpublished="RFC 1340 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1340", + pages="1--139", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1700", +url="https://www.rfc-editor.org/rfc/rfc1340.txt", + key="RFC 1340", + abstract={This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.}, + doi="10.17487/RFC1340", + } + +@misc{rfc1341, + author="N. Borenstein and N. Freed", + title="{MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies}", + howpublished="RFC 1341 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1341", + pages="1--80", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1521", +url="https://www.rfc-editor.org/rfc/rfc1341.txt", + key="RFC 1341", + abstract={This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]}, + keywords="EMail, Multimedia", + doi="10.17487/RFC1341", + } + +@misc{rfc1342, + author="K. Moore", + title="{Representation of Non-ASCII Text in Internet Message Headers}", + howpublished="RFC 1342 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1342", + pages="1--7", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1522", +url="https://www.rfc-editor.org/rfc/rfc1342.txt", + key="RFC 1342", + abstract={This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as ``RFC 1341''), to allow the representation of character sets other than ASCII in RFC 822 message headers. [STANDARDS-TRACK]}, + keywords="EMail, Character Sets", + doi="10.17487/RFC1342", + } + +@misc{rfc1343, + author="N. Borenstein", + title="{A User Agent Configuration Mechanism for Multimedia Mail Format Information}", + howpublished="RFC 1343 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1343", + pages="1--10", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1343.txt", + key="RFC 1343", + abstract={This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="EMail, Multimedia", + doi="10.17487/RFC1343", + } + +@misc{rfc1344, + author="N. Borenstein", + title="{Implications of MIME for Internet Mail Gateways}", + howpublished="RFC 1344 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1344", + pages="1--9", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1344.txt", + key="RFC 1344", + abstract={While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="EMail, Forwarding, Relaying, Fragmentation, Multimedia", + doi="10.17487/RFC1344", + } + +@misc{rfc1345, + author="K. Simonsen", + title="{Character Mnemonics and Character Sets}", + howpublished="RFC 1345 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1345", + pages="1--103", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1345.txt", + key="RFC 1345", + abstract={This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1345", + } + +@misc{rfc1346, + author="P. Jones", + title="{Resource Allocation, Control, and Accounting for the Use of Network Resources}", + howpublished="RFC 1346 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1346", + pages="1--6", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1346.txt", + key="RFC 1346", + abstract={The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1346", + } + +@misc{rfc1347, + author="R. Callon", + title="{TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing}", + howpublished="RFC 1347 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1347", + pages="1--8", + year=1992, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1347.txt", + key="RFC 1347", + abstract={This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1347", + } + +@misc{rfc1348, + author="B. Manning", + title="{DNS NSAP RRs}", + howpublished="RFC 1348 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1348", + pages="1--4", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1637", +url="https://www.rfc-editor.org/rfc/rfc1348.txt", + key="RFC 1348", + abstract={This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.}, + keywords="domain names, CLNP, resource records", + doi="10.17487/RFC1348", + } + +@misc{rfc1349, + author="P. Almquist", + title="{Type of Service in the Internet Protocol Suite}", + howpublished="RFC 1349 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1349", + pages="1--28", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2474", +url="https://www.rfc-editor.org/rfc/rfc1349.txt", + key="RFC 1349", + abstract={This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]}, + keywords="TOS, TOS, IP", + doi="10.17487/RFC1349", + } + +@misc{rfc1350, + author="K. Sollins", + title="{The TFTP Protocol (Revision 2)}", + howpublished="RFC 1350 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1350", + pages="1--11", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1782, 1783, 1784, 1785, 2347, 2348, 2349", +url="https://www.rfc-editor.org/rfc/rfc1350.txt", + key="RFC 1350", + abstract={TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]}, + keywords="TFTP, trivial, file, transfer, booting", + doi="10.17487/RFC1350", + } + +@misc{rfc1351, + author="J. Davin and J. Galvin and K. McCloghrie", + title="{SNMP Administrative Model}", + howpublished="RFC 1351 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1351", + pages="1--35", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1351.txt", + key="RFC 1351", + abstract={This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]}, + keywords="SNMP-ADMIN, network, management, authentication", + doi="10.17487/RFC1351", + } + +@misc{rfc1352, + author="J. Galvin and K. McCloghrie and J. Davin", + title="{SNMP Security Protocols}", + howpublished="RFC 1352 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1352", + pages="1--41", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1352.txt", + key="RFC 1352", + abstract={The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]}, + keywords="SNMP-SEC, network, management, authentication", + doi="10.17487/RFC1352", + } + +@misc{rfc1353, + author="K. McCloghrie and J. Davin and J. Galvin", + title="{Definitions of Managed Objects for Administration of SNMP Parties}", + howpublished="RFC 1353 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1353", + pages="1--26", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1353.txt", + key="RFC 1353", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet Standard SMI [1]. [STANDARDS-TRACK]}, + keywords="SNMP-PARTY-MIB, network, management, authentication", + doi="10.17487/RFC1353", + } + +@misc{rfc1354, + author="F. Baker", + title="{IP Forwarding Table MIB}", + howpublished="RFC 1354 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1354", + pages="1--12", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2096", +url="https://www.rfc-editor.org/rfc/rfc1354.txt", + key="RFC 1354", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing routes in the IP Internet. [STANDARDS-TRACK]}, + keywords="Network, Management, Route, Table", + doi="10.17487/RFC1354", + } + +@misc{rfc1355, + author="J. Curran and A. Marine", + title="{Privacy and Accuracy Issues in Network Information Center Databases}", + howpublished="RFC 1355 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1355", + pages="1--4", + year=1992, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1355.txt", + key="RFC 1355", + abstract={This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="NIC, data, privacy, accuracy", + doi="10.17487/RFC1355", + } + +@misc{rfc1356, + author="A. Malis and D. Robinson and R. Ullmann", + title="{Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode}", + howpublished="RFC 1356 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1356", + pages="1--14", + year=1992, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1356.txt", + key="RFC 1356", + abstract={This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards. It is a replacement for RFC 877, ``A Standard for the Transmission of IP Datagrams Over Public Data Networks'' [1]. [STANDARDS-TRACK]}, + keywords="IP-X.25, IP, on, X.25", + doi="10.17487/RFC1356", + } + +@misc{rfc1357, + author="D. Cohen", + title="{A Format for E-mailing Bibliographic Records}", + howpublished="RFC 1357 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1357", + pages="1--13", + year=1992, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1807", +url="https://www.rfc-editor.org/rfc/rfc1357.txt", + key="RFC 1357", + abstract={This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="library, technical, reports, email, services", + doi="10.17487/RFC1357", + } + +@misc{rfc1358, + author="L. Chapin", + title="{Charter of the Internet Architecture Board (IAB)}", + howpublished="RFC 1358 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1358", + pages="1--5", + year=1992, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1601", +url="https://www.rfc-editor.org/rfc/rfc1358.txt", + key="RFC 1358", + abstract={The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="ISOC, Internet, Society, IETF, IRTF", + doi="10.17487/RFC1358", + } + +@misc{rfc1359, + author="ACM SIGUCCS", + title="{Connecting to the Internet - What Connecting Institutions Should Anticipate}", + howpublished="RFC 1359 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1359", + pages="1--25", + year=1992, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1359.txt", + key="RFC 1359", + abstract={This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Internet, access", + doi="10.17487/RFC1359", + } + +@misc{rfc1360, + author="J. Postel", + title="{IAB Official Protocol Standards}", + howpublished="RFC 1360 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1360", + pages="1--33", + year=1992, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1410", +url="https://www.rfc-editor.org/rfc/rfc1360.txt", + key="RFC 1360", + keywords="proposed, draft, experimental, informational, historic, full", + doi="10.17487/RFC1360", + } + +@misc{rfc1361, + author="D. Mills", + title="{Simple Network Time Protocol (SNTP)}", + howpublished="RFC 1361 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1361", + pages="1--10", + year=1992, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1769", +url="https://www.rfc-editor.org/rfc/rfc1361.txt", + key="RFC 1361", + abstract={This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memorandum does not obsolete or update any RFC. This memo provides information for the Internet community. It does not specify an Internet standard. Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization. Finally come pointers to references and contacts for further information. [STANDARDS-TRACK]}, + keywords="Clocks, Synchronization, NTP", + doi="10.17487/RFC1361", + } + +@misc{rfc1362, + author="M. Allen", + title="{Novell IPX over Various WAN Media (IPXWAN)}", + howpublished="RFC 1362 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1362", + pages="1--13", + year=1992, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1634", +url="https://www.rfc-editor.org/rfc/rfc1362.txt", + key="RFC 1362", + abstract={This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common ``IPX WAN'' protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="IPX on X.25, IPX on PPP, IPX on Frame Relay", + doi="10.17487/RFC1362", + } + +@misc{rfc1363, + author="C. Partridge", + title="{A Proposed Flow Specification}", + howpublished="RFC 1363 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1363", + pages="1--20", + year=1992, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1363.txt", + key="RFC 1363", + keywords="flow, spec, resource, reservation, stream, type of service, quality of service", + doi="10.17487/RFC1363", + } + +@misc{rfc1364, + author="K. Varadhan", + title="{BGP OSPF Interaction}", + howpublished="RFC 1364 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1364", + pages="1--14", + year=1992, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1403", +url="https://www.rfc-editor.org/rfc/rfc1364.txt", + key="RFC 1364", + keywords="autonomous, system, border, router, open, shortest, path, first, routing, protocol, domain, route, exchange, exporting, importing", + doi="10.17487/RFC1364", + } + +@misc{rfc1365, + author="K. Siyan", + title="{An IP Address Extension Proposal}", + howpublished="RFC 1365 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1365", + pages="1--6", + year=1992, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1365.txt", + key="RFC 1365", + keywords="class F addresses", + doi="10.17487/RFC1365", + } + +@misc{rfc1366, + author="E. Gerich", + title="{Guidelines for Management of IP Address Space}", + howpublished="RFC 1366 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1366", + pages="1--8", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1466", +url="https://www.rfc-editor.org/rfc/rfc1366.txt", + key="RFC 1366", + abstract={This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specificati on 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.}, + keywords="routing, tables, allocation, registry, IR, IANA", + doi="10.17487/RFC1366", + } + +@misc{rfc1367, + author="C. Topolcic", + title="{Schedule for IP Address Space Management Guidelines}", + howpublished="RFC 1367 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1367", + pages="1--3", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1467", +url="https://www.rfc-editor.org/rfc/rfc1367.txt", + key="RFC 1367", + abstract={This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="routing, tables, allocation, registry, IR, IANA", + doi="10.17487/RFC1367", + } + +@misc{rfc1368, + author="D. McMaster and K. McCloghrie", + title="{Definition of Managed Objects for IEEE 802.3 Repeater Devices}", + howpublished="RFC 1368 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1368", + pages="1--40", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1516", +url="https://www.rfc-editor.org/rfc/rfc1368.txt", + key="RFC 1368", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as ``hubs''. [STANDARDS-TRACK]}, + keywords="MIB, hub, management", + doi="10.17487/RFC1368", + } + +@misc{rfc1369, + author="F. Kastenholz", + title="{Implementation Notes and Experience for the Internet Ethernet MIB}", + howpublished="RFC 1369 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1369", + pages="1--7", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1369.txt", + key="RFC 1369", + abstract={This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="management", + doi="10.17487/RFC1369", + } + +@misc{rfc1370, + author="Internet Architecture Board and L. Chapin", + title="{Applicability Statement for OSPF}", + howpublished="RFC 1370 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1370", + pages="1--2", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1370.txt", + key="RFC 1370", + abstract={This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]}, + keywords="routing, open, shortest, path, first", + doi="10.17487/RFC1370", + } + +@misc{rfc1371, + author="P. Gross", + title="{Choosing a Common IGP for the IP Internet}", + howpublished="RFC 1371 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1371", + pages="1--9", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1371.txt", + key="RFC 1371", + abstract={This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single ``common IGP'' for the IP portions of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="routing, recommendation, interior, gateway, protocol", + doi="10.17487/RFC1371", + } + +@misc{rfc1372, + author="C. Hedrick and D. Borman", + title="{Telnet Remote Flow Control Option}", + howpublished="RFC 1372 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1372", + pages="1--6", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1372.txt", + key="RFC 1372", + abstract={This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]}, + keywords="TOPT-RFC, terminal, access", + doi="10.17487/RFC1372", + } + +@misc{rfc1373, + author="T. Tignor", + title="{Portable DUAs}", + howpublished="RFC 1373 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1373", + pages="1--12", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1373.txt", + key="RFC 1373", + abstract={This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="directory, user, agents, whois, de, dixie, ud, doog, ISODE, X.500", + doi="10.17487/RFC1373", + } + +@misc{rfc1374, + author="J. Renwick and A. Nicholson", + title="{IP and ARP on HIPPI}", + howpublished="RFC 1374 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1374", + pages="1--43", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2834", +url="https://www.rfc-editor.org/rfc/rfc1374.txt", + key="RFC 1374", + abstract={The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. This memo is intended to become an Internet Standard. [STANDARDS-TRACK]}, + doi="10.17487/RFC1374", + } + +@misc{rfc1375, + author="P. Robinson", + title="{Suggestion for New Classes of IP Addresses}", + howpublished="RFC 1375 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1375", + pages="1--7", + year=1992, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1375.txt", + key="RFC 1375", + abstract={This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="network, numbers", + doi="10.17487/RFC1375", + } + +@misc{rfc1376, + author="S. Senum", + title="{The PPP DECnet Phase IV Control Protocol (DNCP)}", + howpublished="RFC 1376 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1376", + pages="1--6", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1762", +url="https://www.rfc-editor.org/rfc/rfc1376.txt", + key="RFC 1376", + abstract={This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). [STANDARDS-TRACK]}, + keywords="point, DNA, DDCMP", + doi="10.17487/RFC1376", + } + +@misc{rfc1377, + author="D. Katz", + title="{The PPP OSI Network Layer Control Protocol (OSINLCP)}", + howpublished="RFC 1377 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1377", + pages="1--10", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1377.txt", + key="RFC 1377", + abstract={This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK]}, + keywords="PPP-OSINLCP, point, open, systems, interconnection", + doi="10.17487/RFC1377", + } + +@misc{rfc1378, + author="B. Parker", + title="{The PPP AppleTalk Control Protocol (ATCP)}", + howpublished="RFC 1378 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1378", + pages="1--16", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1378.txt", + key="RFC 1378", + abstract={This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK]}, + keywords="PPP-ATCP, point", + doi="10.17487/RFC1378", + } + +@misc{rfc1379, + author="R. Braden", + title="{Extending TCP for Transactions -- Concepts}", + howpublished="RFC 1379 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1379", + pages="1--38", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6247, updated by RFC 1644", +url="https://www.rfc-editor.org/rfc/rfc1379.txt", + key="RFC 1379", + abstract={This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="transmission, control, protocol", + doi="10.17487/RFC1379", + } + +@misc{rfc1380, + author="P. Gross and P. Almquist", + title="{IESG Deliberations on Routing and Addressing}", + howpublished="RFC 1380 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1380", + pages="1--22", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1380.txt", + key="RFC 1380", + abstract={This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="ROAD", + doi="10.17487/RFC1380", + } + +@misc{rfc1381, + author="D. Throop and F. Baker", + title="{SNMP MIB Extension for X.25 LAPB}", + howpublished="RFC 1381 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1381", + pages="1--33", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1381.txt", + key="RFC 1381", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Link Layer of X.25, LAPB. [STANDARDS-TRACK]}, + keywords="SNMP-LAPB, management", + doi="10.17487/RFC1381", + } + +@misc{rfc1382, + author="D. {Throop (Ed.)}", + title="{SNMP MIB Extension for the X.25 Packet Layer}", + howpublished="RFC 1382 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1382", + pages="1--69", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1382.txt", + key="RFC 1382", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]}, + keywords="SNMP-X.25, management", + doi="10.17487/RFC1382", + } + +@misc{rfc1383, + author="C. Huitema", + title="{An Experiment in DNS Based IP Routing}", + howpublished="RFC 1383 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1383", + pages="1--14", + year=1992, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1383.txt", + key="RFC 1383", + abstract={Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DNS-IP", + doi="10.17487/RFC1383", + } + +@misc{rfc1384, + author="P. Barker and S.E. Hardcastle-Kille", + title="{Naming Guidelines for Directory Pilots}", + howpublished="RFC 1384 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1384", + pages="1--12", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1617, NaN", +url="https://www.rfc-editor.org/rfc/rfc1384.txt", + key="RFC 1384", + abstract={This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="X.500, Multinational", + doi="10.17487/RFC1384", + } + +@misc{rfc1385, + author="Z. Wang", + title="{EIP: The Extended Internet Protocol}", + howpublished="RFC 1385 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1385", + pages="1--17", + year=1992, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6814", +url="https://www.rfc-editor.org/rfc/rfc1385.txt", + key="RFC 1385", + abstract={EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an ``idea'' paper and discussion is strongly encouraged on Big-Internet(a)munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="addressing", + doi="10.17487/RFC1385", + } + +@misc{rfc1386, + author="A. Cooper and J. Postel", + title="{The US Domain}", + howpublished="RFC 1386 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1386", + pages="1--31", + year=1992, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1480", +url="https://www.rfc-editor.org/rfc/rfc1386.txt", + key="RFC 1386", + abstract={This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="DNS, top-level", + doi="10.17487/RFC1386", + } + +@misc{rfc1387, + author="G. Malkin", + title="{RIP Version 2 Protocol Analysis}", + howpublished="RFC 1387 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1387", + pages="1--3", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1721", +url="https://www.rfc-editor.org/rfc/rfc1387.txt", + key="RFC 1387", + abstract={As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="RIP-2", + doi="10.17487/RFC1387", + } + +@misc{rfc1388, + author="G. Malkin", + title="{RIP Version 2 Carrying Additional Information}", + howpublished="RFC 1388 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1388", + pages="1--7", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1723", +url="https://www.rfc-editor.org/rfc/rfc1388.txt", + key="RFC 1388", + abstract={This document specifies an extension of the Routing Information Protocol (RIP), as defined in [STANDARDS-TRACK]}, + keywords="RIP-2", + doi="10.17487/RFC1388", + } + +@misc{rfc1389, + author="G. Malkin and F. Baker", + title="{RIP Version 2 MIB Extensions}", + howpublished="RFC 1389 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1389", + pages="1--13", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1724", +url="https://www.rfc-editor.org/rfc/rfc1389.txt", + key="RFC 1389", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]}, + keywords="RIP-2, Management, Information, Base", + doi="10.17487/RFC1389", + } + +@misc{rfc1390, + author="D. Katz", + title="{Transmission of IP and ARP over FDDI Networks}", + howpublished="RFC 1390 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1390", + pages="1--11", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1390.txt", + key="RFC 1390", + abstract={This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]}, + keywords="IP-FDDI, IEEE, 802, MAC", + doi="10.17487/RFC1390", + } + +@misc{rfc1391, + author="G. Malkin", + title="{The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force}", + howpublished="RFC 1391 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1391", + pages="1--19", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1539", +url="https://www.rfc-editor.org/rfc/rfc1391.txt", + key="RFC 1391", + abstract={The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="meetings", + doi="10.17487/RFC1391", + } + +@misc{rfc1392, + author="G. Malkin and T. LaQuey Parker", + title="{Internet Users' Glossary}", + howpublished="RFC 1392 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1392", + pages="1--53", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1983", +url="https://www.rfc-editor.org/rfc/rfc1392.txt", + key="RFC 1392", + abstract={There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1392", + } + +@misc{rfc1393, + author="G. Malkin", + title="{Traceroute Using an IP Option}", + howpublished="RFC 1393 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1393", + pages="1--7", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6814", +url="https://www.rfc-editor.org/rfc/rfc1393.txt", + key="RFC 1393", + abstract={This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TRACE-IP, ICMP, MTU, Line, Speed", + doi="10.17487/RFC1393", + } + +@misc{rfc1394, + author="P. Robinson", + title="{Relationship of Telex Answerback Codes to Internet Domains}", + howpublished="RFC 1394 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1394", + pages="1--15", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1394.txt", + key="RFC 1394", + abstract={This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available. It will also list major Internet ``Public'' E-Mail addresses. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="DNS, Country", + doi="10.17487/RFC1394", + } + +@misc{rfc1395, + author="J. Reynolds", + title="{BOOTP Vendor Information Extensions}", + howpublished="RFC 1395 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1395", + pages="1--8", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1497, 1533", +url="https://www.rfc-editor.org/rfc/rfc1395.txt", + key="RFC 1395", + abstract={This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).}, + keywords="TAGS", + doi="10.17487/RFC1395", + } + +@misc{rfc1396, + author="S. Crocker", + title="{The Process for Organization of Internet Standards Working Group (POISED)}", + howpublished="RFC 1396 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1396", + pages="1--10", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1396.txt", + key="RFC 1396", + abstract={This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="IAB, IESG, ISOC", + doi="10.17487/RFC1396", + } + +@misc{rfc1397, + author="D. Haskin", + title="{Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol}", + howpublished="RFC 1397 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1397", + pages="1--2", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1397.txt", + key="RFC 1397", + abstract={This document speficies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol. [STANDARDS-TRACK]}, + keywords="BGP", + doi="10.17487/RFC1397", + } + +@misc{rfc1398, + author="F. Kastenholz", + title="{Definitions of Managed Objects for the Ethernet-Like Interface Types}", + howpublished="RFC 1398 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1398", + pages="1--17", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1623", +url="https://www.rfc-editor.org/rfc/rfc1398.txt", + key="RFC 1398", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ehternet-like objects. [STANDARDS-TRACK]}, + keywords="MIB, Management", + doi="10.17487/RFC1398", + } + +@misc{rfc1399, + author="J. Elliott", + title="{Summary of 1300-1399}", + howpublished="RFC 1399 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1399", + pages="1--22", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1399.txt", + key="RFC 1399", + keywords="Index", + doi="10.17487/RFC1399", + } + +@misc{rfc1400, + author="S. Williamson", + title="{Transition and Modernization of the Internet Registration Service}", + howpublished="RFC 1400 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1400", + pages="1--7", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1400.txt", + key="RFC 1400", + abstract={As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="INTERNIC IR", + doi="10.17487/RFC1400", + } + +@misc{rfc1401, + author="Internet Architecture Board", + title="{Correspondence between the IAB and DISA on the use of DNS}", + howpublished="RFC 1401 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1401", + pages="1--8", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1401.txt", + key="RFC 1401", + abstract={This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as ``hosts.txt''. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Domain Name, Milnet", + doi="10.17487/RFC1401", + } + +@misc{rfc1402, + author="J. Martin", + title="{There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places}", + howpublished="RFC 1402 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1402", + pages="1--39", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1402.txt", + key="RFC 1402", + abstract={The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer. This RFC provides information for the Internet community. It does not specify an Internet standard.}, + keywords="information, introduction, SIGUCCS, User Services, Help", + doi="10.17487/RFC1402", + } + +@misc{rfc1403, + author="K. Varadhan", + title="{BGP OSPF Interaction}", + howpublished="RFC 1403 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1403", + pages="1--17", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1403.txt", + key="RFC 1403", + abstract={This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]}, + keywords="BGP-OSPF, border gateway protocol, open shortest path first routing", + doi="10.17487/RFC1403", + } + +@misc{rfc1404, + author="B. Stockman", + title="{A Model for Common Operational Statistics}", + howpublished="RFC 1404 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1404", + pages="1--27", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1857", +url="https://www.rfc-editor.org/rfc/rfc1404.txt", + key="RFC 1404", + abstract={This memo describes a model for operational statistics in the Internet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Management, Operations", + doi="10.17487/RFC1404", + } + +@misc{rfc1405, + author="C. Allocchio", + title="{Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)}", + howpublished="RFC 1405 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1405", + pages="1--19", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2162", +url="https://www.rfc-editor.org/rfc/rfc1405.txt", + key="RFC 1405", + abstract={This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SMTP, EMail, 822", + doi="10.17487/RFC1405", + } + +@misc{rfc1406, + author="F. {Baker (Ed.)} and J. {Watt (Ed.)}", + title="{Definitions of Managed Objects for the DS1 and E1 Interface Types}", + howpublished="RFC 1406 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1406", + pages="1--50", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2495", +url="https://www.rfc-editor.org/rfc/rfc1406.txt", + key="RFC 1406", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. [STANDARDS-TRACK]}, + keywords="DS1/E1-MIB, T1, MIB, Management, SNMP", + doi="10.17487/RFC1406", + } + +@misc{rfc1407, + author="T. Cox and K. Tesink", + title="{Definitions of Managed Objects for the DS3/E3 Interface Type}", + howpublished="RFC 1407 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1407", + pages="1--43", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2496", +url="https://www.rfc-editor.org/rfc/rfc1407.txt", + key="RFC 1407", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3 Interfaces. [STANDARDS-TRACK]}, + keywords="DS3/E3-MIB, T3, MIB, Management, SNMP", + doi="10.17487/RFC1407", + } + +@misc{rfc1408, + author="D. {Borman (Ed.)}", + title="{Telnet Environment Option}", + howpublished="RFC 1408 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1408", + pages="1--7", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1571", +url="https://www.rfc-editor.org/rfc/rfc1408.txt", + key="RFC 1408", + abstract={This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK]}, + keywords="TOPT-ENVIR, Negotiation", + doi="10.17487/RFC1408", + } + +@misc{rfc1409, + author="D. {Borman (Ed.)}", + title="{Telnet Authentication Option}", + howpublished="RFC 1409 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1409", + pages="1--7", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1416", +url="https://www.rfc-editor.org/rfc/rfc1409.txt", + key="RFC 1409", + abstract={This memo defines an Experimental Protocol for the Internet community.}, + keywords="security", + doi="10.17487/RFC1409", + } + +@misc{rfc1410, + author="J. {Postel (Ed.)}", + title="{IAB Official Protocol Standards}", + howpublished="RFC 1410 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1410", + pages="1--35", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1500", +url="https://www.rfc-editor.org/rfc/rfc1410.txt", + key="RFC 1410", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).}, + keywords="proposed, draft, experimental, informational, historic, full", + doi="10.17487/RFC1410", + } + +@misc{rfc1411, + author="D. {Borman (Ed.)}", + title="{Telnet Authentication: Kerberos Version 4}", + howpublished="RFC 1411 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1411", + pages="1--4", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1411.txt", + key="RFC 1411", + abstract={This memo defines an Experimental Protocol for the Internet community.}, + keywords="TEL-KER, Security, option", + doi="10.17487/RFC1411", + } + +@misc{rfc1412, + author="K. Alagappan", + title="{Telnet Authentication: SPX}", + howpublished="RFC 1412 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1412", + pages="1--4", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1412.txt", + key="RFC 1412", + abstract={This memo defines an Experimental Protocol for the Internet community.}, + keywords="TEL-SPX, Security, option", + doi="10.17487/RFC1412", + } + +@misc{rfc1413, + author="M. St. Johns", + title="{Identification Protocol}", + howpublished="RFC 1413 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1413", + pages="1--8", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1413.txt", + key="RFC 1413", + abstract={The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]}, + keywords="IDENT, Authentication", + doi="10.17487/RFC1413", + } + +@misc{rfc1414, + author="M. St. Johns and M. Rose", + title="{Identification MIB}", + howpublished="RFC 1414 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1414", + pages="1--7", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1414.txt", + key="RFC 1414", + abstract={This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. [STANDARDS-TRACK]}, + keywords="IDENT-MIB, Management, SNMP", + doi="10.17487/RFC1414", + } + +@misc{rfc1415, + author="J. Mindel and R. Slaski", + title="{FTP-FTAM Gateway Specification}", + howpublished="RFC 1415 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1415", + pages="1--58", + year=1993, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1415.txt", + key="RFC 1415", + abstract={This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. [STANDARDS-TRACK]}, + keywords="FTP, FTAM, transfer, ISO, OSI", + doi="10.17487/RFC1415", + } + +@misc{rfc1416, + author="D. {Borman (Ed.)}", + title="{Telnet Authentication Option}", + howpublished="RFC 1416 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1416", + pages="1--7", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2941", +url="https://www.rfc-editor.org/rfc/rfc1416.txt", + key="RFC 1416", + abstract={This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of ``REPLY'' should be ``IS''). This memo defines an Experimental Protocol for the Internet community.}, + keywords="TOPT-AUTH, Security", + doi="10.17487/RFC1416", + } + +@misc{rfc1417, + author="The North American Directory Forum", + title="{NADF Standing Documents: A Brief Overview}", + howpublished="RFC 1417 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1417", + pages="1--4", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1758", +url="https://www.rfc-editor.org/rfc/rfc1417.txt", + key="RFC 1417", + abstract={The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="X.500, Directory", + doi="10.17487/RFC1417", + } + +@misc{rfc1418, + author="M. Rose", + title="{SNMP over OSI}", + howpublished="RFC 1418 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1418", + pages="1--4", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1418.txt", + key="RFC 1418", + abstract={This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]}, + keywords="SNMP-OSI, Management", + doi="10.17487/RFC1418", + } + +@misc{rfc1419, + author="G. Minshall and M. Ritter", + title="{SNMP over AppleTalk}", + howpublished="RFC 1419 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1419", + pages="1--7", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1419.txt", + key="RFC 1419", + abstract={This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]}, + keywords="SNMP-AT, Management", + doi="10.17487/RFC1419", + } + +@misc{rfc1420, + author="S. Bostock", + title="{SNMP over IPX}", + howpublished="RFC 1420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1420", + pages="1--4", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1420.txt", + key="RFC 1420", + abstract={This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. [STANDARDS-TRACK]}, + keywords="SNMP-IPX, Management", + doi="10.17487/RFC1420", + } + +@misc{rfc1421, + author="J. Linn", + title="{Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures}", + howpublished="RFC 1421 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1421", + pages="1--42", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1421.txt", + key="RFC 1421", + abstract={This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]}, + keywords="PEM-ENC, PEM", + doi="10.17487/RFC1421", + } + +@misc{rfc1422, + author="S. Kent", + title="{Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management}", + howpublished="RFC 1422 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1422", + pages="1--32", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1422.txt", + key="RFC 1422", + abstract={This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]}, + keywords="PEM-CKM, PEM", + doi="10.17487/RFC1422", + } + +@misc{rfc1423, + author="D. Balenson", + title="{Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers}", + howpublished="RFC 1423 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1423", + pages="1--14", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1423.txt", + key="RFC 1423", + abstract={This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK]}, + keywords="PEM-ALG, PEM", + doi="10.17487/RFC1423", + } + +@misc{rfc1424, + author="B. Kaliski", + title="{Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services}", + howpublished="RFC 1424 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1424", + pages="1--9", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1424.txt", + key="RFC 1424", + abstract={This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]}, + keywords="PEM-KEY, PEM", + doi="10.17487/RFC1424", + } + +@misc{rfc1425, + author="J. Klensin and N. {Freed (Ed.)} and M. Rose and E. Stefferud and D. Crocker", + title="{SMTP Service Extensions}", + howpublished="RFC 1425 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1425", + pages="1--10", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1651", +url="https://www.rfc-editor.org/rfc/rfc1425.txt", + key="RFC 1425", + abstract={This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]}, + keywords="Mail", + doi="10.17487/RFC1425", + } + +@misc{rfc1426, + author="J. Klensin and N. {Freed (Ed.)} and M. Rose and E. Stefferud and D. Crocker", + title="{SMTP Service Extension for 8bit-MIMEtransport}", + howpublished="RFC 1426 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1426", + pages="1--6", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1652", +url="https://www.rfc-editor.org/rfc/rfc1426.txt", + key="RFC 1426", + abstract={This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex}, + keywords="Mail", + doi="10.17487/RFC1426", + } + +@misc{rfc1427, + author="J. Klensin and N. {Freed (Ed.)} and K. Moore", + title="{SMTP Service Extension for Message Size Declaration}", + howpublished="RFC 1427 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1427", + pages="1--8", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1653", +url="https://www.rfc-editor.org/rfc/rfc1427.txt", + key="RFC 1427", + abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]}, + keywords="Mail", + doi="10.17487/RFC1427", + } + +@misc{rfc1428, + author="G. Vaudreuil", + title="{Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME}", + howpublished="RFC 1428 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1428", + pages="1--6", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1428.txt", + key="RFC 1428", + abstract={This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. This RFC provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Mail", + doi="10.17487/RFC1428", + } + +@misc{rfc1429, + author="E. Thomas", + title="{Listserv Distribute Protocol}", + howpublished="RFC 1429 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1429", + pages="1--8", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1429.txt", + key="RFC 1429", + abstract={This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="LISTSERV, Mail", + doi="10.17487/RFC1429", + } + +@misc{rfc1430, + author="S. Hardcastle-Kille and E. Huizer and V. Cerf and R. Hobby and S. Kent", + title="{A Strategic Plan for Deploying an Internet X.500 Directory Service}", + howpublished="RFC 1430 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1430", + pages="1--20", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1430.txt", + key="RFC 1430", + abstract={This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="X.500", + doi="10.17487/RFC1430", + } + +@misc{rfc1431, + author="P. Barker", + title="{DUA Metrics (OSI-DS 33 (v2))}", + howpublished="RFC 1431 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1431", + pages="1--19", + year=1993, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1431.txt", + key="RFC 1431", + abstract={This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Directory User Agent, Measurement, Statistics, Survey, X.500", + doi="10.17487/RFC1431", + } + +@misc{rfc1432, + author="J. Quarterman", + title="{Recent Internet Books}", + howpublished="RFC 1432 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1432", + pages="1--15", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1432.txt", + key="RFC 1432", + abstract={Here is a list of books related to using the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="bibiography", + doi="10.17487/RFC1432", + } + +@misc{rfc1433, + author="J. Garrett and J. Hagan and J. Wong", + title="{Directed ARP}", + howpublished="RFC 1433 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1433", + pages="1--18", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1433.txt", + key="RFC 1433", + abstract={Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DIR-ARP, public networks, SMDS", + doi="10.17487/RFC1433", + } + +@misc{rfc1434, + author="R. Dixon and D. Kushi", + title="{Data Link Switching: Switch-to-Switch Protocol}", + howpublished="RFC 1434 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1434", + pages="1--33", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1795", +url="https://www.rfc-editor.org/rfc/rfc1434.txt", + key="RFC 1434", + abstract={This RFC describes IBM's support of Data Link Switching over TCP/IP. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="IBM, SNA, DLS, SSP, NetBIos", + doi="10.17487/RFC1434", + } + +@misc{rfc1435, + author="S. Knowles", + title="{IESG Advice from Experience with Path MTU Discovery}", + howpublished="RFC 1435 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1435", + pages="1--2", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1435.txt", + key="RFC 1435", + abstract={In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Maximum, Transmission, Unit", + doi="10.17487/RFC1435", + } + +@misc{rfc1436, + author="F. Anklesaria and M. McCahill and P. Lindner and D. Johnson and D. Torrey and B. Albert", + title="{The Internet Gopher Protocol (a distributed document search and retrieval protocol)}", + howpublished="RFC 1436 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1436", + pages="1--16", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1436.txt", + key="RFC 1436", + abstract={This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="GOPHER, information, locating", + doi="10.17487/RFC1436", + } + +@misc{rfc1437, + author="N. Borenstein and M. Linimon", + title="{The Extension of MIME Content-Types to a New Medium}", + howpublished="RFC 1437 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1437", + pages="1--6", + year=1993, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1437.txt", + key="RFC 1437", + abstract={This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="life form, Matter, transport, Sentient", + doi="10.17487/RFC1437", + } + +@misc{rfc1438, + author="A. Lyman Chapin and C. Huitema", + title="{Internet Engineering Task Force Statements Of Boredom (SOBs)}", + howpublished="RFC 1438 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1438", + pages="1--2", + year=1993, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1438.txt", + key="RFC 1438", + abstract={This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="process, policy", + doi="10.17487/RFC1438", + } + +@misc{rfc1439, + author="C. Finseth", + title="{The Uniqueness of Unique Identifiers}", + howpublished="RFC 1439 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1439", + pages="1--11", + year=1993, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1439.txt", + key="RFC 1439", + abstract={This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="names", + doi="10.17487/RFC1439", + } + +@misc{rfc1440, + author="R. Troth", + title="{SIFT/UFT: Sender-Initiated/Unsolicited File Transfer}", + howpublished="RFC 1440 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1440", + pages="1--9", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1440.txt", + key="RFC 1440", + abstract={This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SIFT, UFT, Send, FTP", + doi="10.17487/RFC1440", + } + +@misc{rfc1441, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Introduction to version 2 of the Internet-standard Network Management Framework}", + howpublished="RFC 1441 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1441", + pages="1--13", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1441.txt", + key="RFC 1441", + abstract={The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]}, + keywords="SNMPv2, SNMP, Management, Framework", + doi="10.17487/RFC1441", + } + +@misc{rfc1442, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1442 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1442", + pages="1--56", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1902", +url="https://www.rfc-editor.org/rfc/rfc1442.txt", + key="RFC 1442", + abstract={Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework, SMI", + doi="10.17487/RFC1442", + } + +@misc{rfc1443, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1443 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1443", + pages="1--31", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1903", +url="https://www.rfc-editor.org/rfc/rfc1443.txt", + key="RFC 1443", + abstract={It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1443", + } + +@misc{rfc1444, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1444 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1444", + pages="1--33", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1904", +url="https://www.rfc-editor.org/rfc/rfc1444.txt", + key="RFC 1444", + abstract={It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1444", + } + +@misc{rfc1445, + author="J. Galvin and K. McCloghrie", + title="{Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1445 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1445", + pages="1--48", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1445.txt", + key="RFC 1445", + abstract={It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1445", + } + +@misc{rfc1446, + author="J. Galvin and K. McCloghrie", + title="{Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1446 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1446", + pages="1--52", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1446.txt", + key="RFC 1446", + abstract={It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1446", + } + +@misc{rfc1447, + author="K. McCloghrie and J. Galvin", + title="{Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1447 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1447", + pages="1--50", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1447.txt", + key="RFC 1447", + abstract={The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1447", + } + +@misc{rfc1448, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1448 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1448", + pages="1--36", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1905", +url="https://www.rfc-editor.org/rfc/rfc1448.txt", + key="RFC 1448", + abstract={It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1448", + } + +@misc{rfc1449, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1449 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1449", + pages="1--25", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1906", +url="https://www.rfc-editor.org/rfc/rfc1449.txt", + key="RFC 1449", + abstract={It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1449", + } + +@misc{rfc1450, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1450 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1450", + pages="1--27", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1907", +url="https://www.rfc-editor.org/rfc/rfc1450.txt", + key="RFC 1450", + abstract={It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1450", + } + +@misc{rfc1451, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Manager-to-Manager Management Information Base}", + howpublished="RFC 1451 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1451", + pages="1--36", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1451.txt", + key="RFC 1451", + abstract={It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1451", + } + +@misc{rfc1452, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework}", + howpublished="RFC 1452 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1452", + pages="1--17", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1908", +url="https://www.rfc-editor.org/rfc/rfc1452.txt", + key="RFC 1452", + abstract={The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]}, + keywords="SNMP, Management, Framework", + doi="10.17487/RFC1452", + } + +@misc{rfc1453, + author="W. Chimiak", + title="{A Comment on Packet Video Remote Conferencing and the Transport/Network Layers}", + howpublished="RFC 1453 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1453", + pages="1--10", + year=1993, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1453.txt", + key="RFC 1453", + abstract={This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="XTP", + doi="10.17487/RFC1453", + } + +@misc{rfc1454, + author="T. Dixon", + title="{Comparison of Proposals for Next Version of IP}", + howpublished="RFC 1454 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1454", + pages="1--15", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1454.txt", + key="RFC 1454", + abstract={This is a slightly edited reprint of RARE Technical Report (RTC(93)004). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="IPng, PIP, TUBA, SIP", + doi="10.17487/RFC1454", + } + +@misc{rfc1455, + author="D. {Eastlake 3rd}", + title="{Physical Link Security Type of Service}", + howpublished="RFC 1455 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1455", + pages="1--6", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2474", +url="https://www.rfc-editor.org/rfc/rfc1455.txt", + key="RFC 1455", + abstract={This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TOS-LS, TOS", + doi="10.17487/RFC1455", + } + +@misc{rfc1456, + author="Vietnamese Standardization Working Group", + title="{Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification}", + howpublished="RFC 1456 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1456", + pages="1--7", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1456.txt", + key="RFC 1456", + abstract={This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Character, Set", + doi="10.17487/RFC1456", + } + +@misc{rfc1457, + author="R. Housley", + title="{Security Label Framework for the Internet}", + howpublished="RFC 1457 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1457", + pages="1--14", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1457.txt", + key="RFC 1457", + abstract={This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1457", + } + +@misc{rfc1458, + author="R. Braudes and S. Zabele", + title="{Requirements for Multicast Protocols}", + howpublished="RFC 1458 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1458", + pages="1--19", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1458.txt", + key="RFC 1458", + abstract={This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Real-Time", + doi="10.17487/RFC1458", + } + +@misc{rfc1459, + author="J. Oikarinen and D. Reed", + title="{Internet Relay Chat Protocol}", + howpublished="RFC 1459 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1459", + pages="1--65", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2810, 2811, 2812, 2813, 7194", +url="https://www.rfc-editor.org/rfc/rfc1459.txt", + key="RFC 1459", + abstract={The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. This memo defines an Experimental Protocol for the Internet community.}, + keywords="IRCP, IRC", + doi="10.17487/RFC1459", + } + +@misc{rfc1460, + author="M. Rose", + title="{Post Office Protocol - Version 3}", + howpublished="RFC 1460 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1460", + pages="1--17", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1725", +url="https://www.rfc-editor.org/rfc/rfc1460.txt", + key="RFC 1460", + abstract={This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]}, + keywords="Email", + doi="10.17487/RFC1460", + } + +@misc{rfc1461, + author="D. Throop", + title="{SNMP MIB extension for Multiprotocol Interconnect over X.25}", + howpublished="RFC 1461 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1461", + pages="1--21", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1461.txt", + key="RFC 1461", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Multiprotocol Interconnect (including IP) traffic carried over X.25. [STANDARDS-TRACK]}, + keywords="X25-MIB", + doi="10.17487/RFC1461", + } + +@misc{rfc1462, + author="E. Krol and E. Hoffman", + title="{FYI on ``What is the Internet?''}", + howpublished="RFC 1462 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1462", + pages="1--11", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1462.txt", + key="RFC 1462", + abstract={This FYI RFC answers the question, ``What is the Internet?'' and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Introduction", + doi="10.17487/RFC1462", + } + +@misc{rfc1463, + author="E. Hoffman and L. Jackson", + title="{FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings}", + howpublished="RFC 1463 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1463", + pages="1--4", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1463.txt", + key="RFC 1463", + abstract={This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1463", + } + +@misc{rfc1464, + author="R. Rosenbaum", + title="{Using the Domain Name System To Store Arbitrary String Attributes}", + howpublished="RFC 1464 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1464", + pages="1--4", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1464.txt", + key="RFC 1464", + abstract={This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DNS, TXT", + doi="10.17487/RFC1464", + } + +@misc{rfc1465, + author="D. Eppenberger", + title="{Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing}", + howpublished="RFC 1465 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1465", + pages="1--31", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1465.txt", + key="RFC 1465", + abstract={This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community.}, + keywords="X400", + doi="10.17487/RFC1465", + } + +@misc{rfc1466, + author="E. Gerich", + title="{Guidelines for Management of IP Address Space}", + howpublished="RFC 1466 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1466", + pages="1--10", + year=1993, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2050", +url="https://www.rfc-editor.org/rfc/rfc1466.txt", + key="RFC 1466", + abstract={This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="CIDR", + doi="10.17487/RFC1466", + } + +@misc{rfc1467, + author="C. Topolcic", + title="{Status of CIDR Deployment in the Internet}", + howpublished="RFC 1467 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1467", + pages="1--9", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1467.txt", + key="RFC 1467", + abstract={This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="routing, tables, allocation, registry, IR, IANA, classless", + doi="10.17487/RFC1467", + } + +@misc{rfc1468, + author="J. Murai and M. Crispin and E. van der Poel", + title="{Japanese Character Encoding for Internet Messages}", + howpublished="RFC 1468 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1468", + pages="1--6", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1468.txt", + key="RFC 1468", + abstract={This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Set", + doi="10.17487/RFC1468", + } + +@misc{rfc1469, + author="T. Pusateri", + title="{IP Multicast over Token-Ring Local Area Networks}", + howpublished="RFC 1469 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1469", + pages="1--4", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1469.txt", + key="RFC 1469", + abstract={This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]}, + keywords="IP-TR-MC, 802.2, 802.5", + doi="10.17487/RFC1469", + } + +@misc{rfc1470, + author="R. Enger and J. Reynolds", + title="{FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices}", + howpublished="RFC 1470 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1470", + pages="1--192", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1470.txt", + key="RFC 1470", + abstract={The goal of this FYI memo is to provide an update to FYI 2, RFC 1147 [1], which provided practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="NOCTOOLS", + doi="10.17487/RFC1470", + } + +@misc{rfc1471, + author="F. Kastenholz", + title="{The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol}", + howpublished="RFC 1471 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1471", + pages="1--25", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1471.txt", + key="RFC 1471", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, \& 12]. [STANDARDS-TRACK]}, + keywords="PPP/LCP MIB, Management, Framework, PPP", + doi="10.17487/RFC1471", + } + +@misc{rfc1472, + author="F. Kastenholz", + title="{The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol}", + howpublished="RFC 1472 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1472", + pages="1--13", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1472.txt", + key="RFC 1472", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, \& 12]. [STANDARDS-TRACK]}, + keywords="PPP/SEC MIB, Management, Framework, PPP", + doi="10.17487/RFC1472", + } + +@misc{rfc1473, + author="F. Kastenholz", + title="{The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol}", + howpublished="RFC 1473 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1473", + pages="1--10", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1473.txt", + key="RFC 1473", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, \& 12]. [STANDARDS-TRACK]}, + keywords="PPP/IP MIB, Management, Framework, PPP", + doi="10.17487/RFC1473", + } + +@misc{rfc1474, + author="F. Kastenholz", + title="{The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol}", + howpublished="RFC 1474 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1474", + pages="1--15", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1474.txt", + key="RFC 1474", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. [STANDARDS-TRACK]}, + keywords="PPP/Bridge, Management, Framework, PPP", + doi="10.17487/RFC1474", + } + +@misc{rfc1475, + author="R. Ullmann", + title="{TP/IX: The Next Internet}", + howpublished="RFC 1475 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1475", + pages="1--35", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6814", +url="https://www.rfc-editor.org/rfc/rfc1475.txt", + key="RFC 1475", + abstract={This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="TP-IX, IPv7, IPng", + doi="10.17487/RFC1475", + } + +@misc{rfc1476, + author="R. Ullmann", + title="{RAP: Internet Route Access Protocol}", + howpublished="RFC 1476 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1476", + pages="1--20", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1476.txt", + key="RFC 1476", + abstract={This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="RAP, Routing", + doi="10.17487/RFC1476", + } + +@misc{rfc1477, + author="M. Steenstrup", + title="{IDPR as a Proposed Standard}", + howpublished="RFC 1477 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1477", + pages="1--13", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1477.txt", + key="RFC 1477", + abstract={This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Routing, Policy", + doi="10.17487/RFC1477", + } + +@misc{rfc1478, + author="M. Steenstrup", + title="{An Architecture for Inter-Domain Policy Routing}", + howpublished="RFC 1478 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1478", + pages="1--35", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1478.txt", + key="RFC 1478", + abstract={We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK]}, + keywords="IDPR-ARCH, IDPR", + doi="10.17487/RFC1478", + } + +@misc{rfc1479, + author="M. Steenstrup", + title="{Inter-Domain Policy Routing Protocol Specification: Version 1}", + howpublished="RFC 1479 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1479", + pages="1--108", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1479.txt", + key="RFC 1479", + abstract={We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]}, + keywords="IDPR, IDPR", + doi="10.17487/RFC1479", + } + +@misc{rfc1480, + author="A. Cooper and J. Postel", + title="{The US Domain}", + howpublished="RFC 1480 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1480", + pages="1--47", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1480.txt", + key="RFC 1480", + abstract={This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="DNS, top-level", + doi="10.17487/RFC1480", + } + +@misc{rfc1481, + author="C. Huitema", + title="{IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling}", + howpublished="RFC 1481 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1481", + pages="1--2", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1481.txt", + key="RFC 1481", + abstract={CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="CIDR", + doi="10.17487/RFC1481", + } + +@misc{rfc1482, + author="M. Knopper and S. Richardson", + title="{Aggregation Support in the NSFNET Policy-Based Routing Database}", + howpublished="RFC 1482 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1482", + pages="1--11", + year=1993, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1482.txt", + key="RFC 1482", + abstract={This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="CIDR", + doi="10.17487/RFC1482", + } + +@misc{rfc1483, + author="Juha Heinanen", + title="{Multiprotocol Encapsulation over ATM Adaptation Layer 5}", + howpublished="RFC 1483 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1483", + pages="1--16", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2684", +url="https://www.rfc-editor.org/rfc/rfc1483.txt", + key="RFC 1483", + abstract={This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK]}, + keywords="ATM-ENCAP, IP, AAL5, over", + doi="10.17487/RFC1483", + } + +@misc{rfc1484, + author="S. Hardcastle-Kille", + title="{Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))}", + howpublished="RFC 1484 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1484", + pages="1--25", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1781, 3494", +url="https://www.rfc-editor.org/rfc/rfc1484.txt", + key="RFC 1484", + abstract={This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="X.500, directory names, representing names", + doi="10.17487/RFC1484", + } + +@misc{rfc1485, + author="S. Hardcastle-Kille", + title="{A String Representation of Distinguished Names (OSI-DS 23 (v5))}", + howpublished="RFC 1485 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1485", + pages="1--7", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1779, 3494", +url="https://www.rfc-editor.org/rfc/rfc1485.txt", + key="RFC 1485", + abstract={When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. [STANDARDS-TRACK]}, + keywords="X.500, directory names, representing names", + doi="10.17487/RFC1485", + } + +@misc{rfc1486, + author="M. Rose and C. Malamud", + title="{An Experiment in Remote Printing}", + howpublished="RFC 1486 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1486", + pages="1--14", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1528, 1529", +url="https://www.rfc-editor.org/rfc/rfc1486.txt", + key="RFC 1486", + abstract={This memo describes a technique for ``remote printing'' using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="electronic mail, facsimile", + doi="10.17487/RFC1486", + } + +@misc{rfc1487, + author="W. Yeong and T. Howes and S. Kille", + title="{X.500 Lightweight Directory Access Protocol}", + howpublished="RFC 1487 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1487", + pages="1--21", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1777, 3494", +url="https://www.rfc-editor.org/rfc/rfc1487.txt", + key="RFC 1487", + abstract={The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]}, + keywords="X.500, DAP, interactive access", + doi="10.17487/RFC1487", + } + +@misc{rfc1488, + author="T. Howes and S. Kille and W. Yeong and C. Robbins", + title="{The X.500 String Representation of Standard Attribute Syntaxes}", + howpublished="RFC 1488 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1488", + pages="1--11", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1778", +url="https://www.rfc-editor.org/rfc/rfc1488.txt", + key="RFC 1488", + abstract={This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. [STANDARDS-TRACK]}, + keywords="X.500, LDAP, lightweight directory protocol", + doi="10.17487/RFC1488", + } + +@misc{rfc1489, + author="A. Chernov", + title="{Registration of a Cyrillic Character Set}", + howpublished="RFC 1489 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1489", + pages="1--5", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1489.txt", + key="RFC 1489", + abstract={Though the proposed character set ``koi8-r'' is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, ``koi8-r'' is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes ``koi8-r'' should be registered. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1489", + } + +@misc{rfc1490, + author="T. Bradley and C. Brown and A. Malis", + title="{Multiprotocol Interconnect over Frame Relay}", + howpublished="RFC 1490 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1490", + pages="1--35", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2427", +url="https://www.rfc-editor.org/rfc/rfc1490.txt", + key="RFC 1490", + abstract={This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU. [STANDARDS-TRACK]}, + keywords="standard, standards, IP, over", + doi="10.17487/RFC1490", + } + +@misc{rfc1491, + author="C. Weider and R. Wright", + title="{A Survey of Advanced Usages of X.500}", + howpublished="RFC 1491 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1491", + pages="1--18", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1491.txt", + key="RFC 1491", + abstract={This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a ``White Pages'' service. This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="directory", + doi="10.17487/RFC1491", + } + +@misc{rfc1492, + author="C. Finseth", + title="{An Access Control Protocol, Sometimes Called TACACS}", + howpublished="RFC 1492 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1492", + pages="1--21", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1492.txt", + key="RFC 1492", + abstract={This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="TACACS, Terminal, Server, TAC", + doi="10.17487/RFC1492", + } + +@misc{rfc1493, + author="E. Decker and P. Langille and A. Rijsinghani and K. McCloghrie", + title="{Definitions of Managed Objects for Bridges}", + howpublished="RFC 1493 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1493", + pages="1--34", + year=1993, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4188", +url="https://www.rfc-editor.org/rfc/rfc1493.txt", + key="RFC 1493", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. [STANDARDS-TRACK]}, + keywords="BRIDGE-MIB, SNMP, MIB, standard, standards", + doi="10.17487/RFC1493", + } + +@misc{rfc1494, + author="H. Alvestrand and S. Thompson", + title="{Equivalences between 1988 X.400 and RFC-822 Message Bodies}", + howpublished="RFC 1494 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1494", + pages="1--19", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1494.txt", + key="RFC 1494", + abstract={This document describes the content of the ``IANA MHS/MIME Equivalence table'', and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]}, + keywords="Equiv, Mail", + doi="10.17487/RFC1494", + } + +@misc{rfc1495, + author="H. Alvestrand and S. Kille and R. Miles and M. Rose and S. Thompson", + title="{Mapping between X.400 and RFC-822 Message Bodies}", + howpublished="RFC 1495 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1495", + pages="1--11", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2156", +url="https://www.rfc-editor.org/rfc/rfc1495.txt", + key="RFC 1495", + abstract={Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]}, + keywords="Mail", + doi="10.17487/RFC1495", + } + +@misc{rfc1496, + author="H. Alvestrand and J. Romaguera and K. Jordan", + title="{Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages}", + howpublished="RFC 1496 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1496", + pages="1--5", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1496.txt", + key="RFC 1496", + abstract={This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]}, + keywords="HARPOON, Mail", + doi="10.17487/RFC1496", + } + +@misc{rfc1497, + author="J. Reynolds", + title="{BOOTP Vendor Information Extensions}", + howpublished="RFC 1497 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1497", + pages="1--8", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1533", +url="https://www.rfc-editor.org/rfc/rfc1497.txt", + key="RFC 1497", + abstract={This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).}, + keywords="TAGS, Boot", + doi="10.17487/RFC1497", + } + +@misc{rfc1498, + author="J. Saltzer", + title="{On the Naming and Binding of Network Destinations}", + howpublished="RFC 1498 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1498", + pages="1--10", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1498.txt", + key="RFC 1498", + abstract={This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="NAMES, Addresses, Routes, Objects, Nodes, Paths", + doi="10.17487/RFC1498", + } + +@misc{rfc1499, + author="J. Elliott", + title="{Summary of 1400-1499}", + howpublished="RFC 1499 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1499", + pages="1--21", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1499.txt", + key="RFC 1499", + keywords="Index", + doi="10.17487/RFC1499", + } + +@misc{rfc1500, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1500 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1500", + pages="1--36", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1540", +url="https://www.rfc-editor.org/rfc/rfc1500.txt", + key="RFC 1500", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]}, + keywords="IAB", + doi="10.17487/RFC1500", + } + +@misc{rfc1501, + author="E. Brunsen", + title="{OS/2 User Group}", + howpublished="RFC 1501 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1501", + pages="1--2", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1501.txt", + key="RFC 1501", + abstract={Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind.}, + doi="10.17487/RFC1501", + } + +@misc{rfc1502, + author="H. Alvestrand", + title="{X.400 Use of Extended Character Sets}", + howpublished="RFC 1502 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1502", + pages="1--14", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1502.txt", + key="RFC 1502", + abstract={This RFC defines a suggested method of using ``GeneralText'' in order to harmonize as much as possible the usage of this body part. [STANDARDS-TRACK]}, + keywords="Mail", + doi="10.17487/RFC1502", + } + +@misc{rfc1503, + author="K. McCloghrie and M. Rose", + title="{Algorithms for Automating Administration in SNMPv2 Managers}", + howpublished="RFC 1503 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1503", + pages="1--14", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1503.txt", + key="RFC 1503", + abstract={When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Management, SNMP", + doi="10.17487/RFC1503", + } + +@misc{rfc1504, + author="A. Oppenheimer", + title="{Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing}", + howpublished="RFC 1504 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1504", + pages="1--82", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1504.txt", + key="RFC 1504", + abstract={This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="AVRP", + doi="10.17487/RFC1504", + } + +@misc{rfc1505, + author="A. Costanzo and D. Robinson and R. Ullmann", + title="{Encoding Header Field for Internet Messages}", + howpublished="RFC 1505 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1505", + pages="1--36", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1505.txt", + key="RFC 1505", + abstract={This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="EHF-MAIL, Mail", + doi="10.17487/RFC1505", + } + +@misc{rfc1506, + author="J. Houttuin", + title="{A Tutorial on Gatewaying between X.400 and Internet Mail}", + howpublished="RFC 1506 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1506", + pages="1--39", + year=1993, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1506.txt", + key="RFC 1506", + abstract={This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="822, email, RTR", + doi="10.17487/RFC1506", + } + +@misc{rfc1507, + author="C. Kaufman", + title="{DASS - Distributed Authentication Security Service}", + howpublished="RFC 1507 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1507", + pages="1--119", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1507.txt", + key="RFC 1507", + abstract={The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="DASS, CAT", + doi="10.17487/RFC1507", + } + +@misc{rfc1508, + author="J. Linn", + title="{Generic Security Service Application Program Interface}", + howpublished="RFC 1508 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1508", + pages="1--49", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2078", +url="https://www.rfc-editor.org/rfc/rfc1508.txt", + key="RFC 1508", + abstract={This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]}, + keywords="CAT,GSS,API", + doi="10.17487/RFC1508", + } + +@misc{rfc1509, + author="J. Wray", + title="{Generic Security Service API : C-bindings}", + howpublished="RFC 1509 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1509", + pages="1--48", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2744", +url="https://www.rfc-editor.org/rfc/rfc1509.txt", + key="RFC 1509", + abstract={This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. [STANDARDS-TRACK]}, + keywords="GSSAPI, CAT,GSS", + doi="10.17487/RFC1509", + } + +@misc{rfc1510, + author="J. Kohl and C. Neuman", + title="{The Kerberos Network Authentication Service (V5)}", + howpublished="RFC 1510 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1510", + pages="1--112", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4120, 6649", +url="https://www.rfc-editor.org/rfc/rfc1510.txt", + key="RFC 1510", + abstract={This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS-TRACK]}, + keywords="KERBEROS, CAT,Security", + doi="10.17487/RFC1510", + } + +@misc{rfc1511, + author="J. Linn", + title="{Common Authentication Technology Overview}", + howpublished="RFC 1511 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1511", + pages="1--2", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1511.txt", + key="RFC 1511", + abstract={This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="CAT,Security", + doi="10.17487/RFC1511", + } + +@misc{rfc1512, + author="J. Case and A. Rijsinghani", + title="{FDDI Management Information Base}", + howpublished="RFC 1512 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1512", + pages="1--51", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1512.txt", + key="RFC 1512", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee.}, + keywords="FDDI-MIB , MIB, SNMP", + doi="10.17487/RFC1512", + } + +@misc{rfc1513, + author="S. Waldbusser", + title="{Token Ring Extensions to the Remote Network Monitoring MIB}", + howpublished="RFC 1513 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1513", + pages="1--55", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1513.txt", + key="RFC 1513", + abstract={This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK]}, + keywords="Monitoring, SNMP", + doi="10.17487/RFC1513", + } + +@misc{rfc1514, + author="P. Grillo and S. Waldbusser", + title="{Host Resources MIB}", + howpublished="RFC 1514 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1514", + pages="1--33", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2790", +url="https://www.rfc-editor.org/rfc/rfc1514.txt", + key="RFC 1514", + abstract={This memo defines a MIB for use with managing host systems. [STANDARDS-TRACK]}, + keywords="HOST-MIB, Management, SNMP", + doi="10.17487/RFC1514", + } + +@misc{rfc1515, + author="D. McMaster and K. McCloghrie and S. Roberts", + title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}", + howpublished="RFC 1515 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1515", + pages="1--25", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3636", +url="https://www.rfc-editor.org/rfc/rfc1515.txt", + key="RFC 1515", + abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). [STANDARDS-TRACK]}, + keywords="MIB, Management, SNMP", + doi="10.17487/RFC1515", + } + +@misc{rfc1516, + author="D. McMaster and K. McCloghrie", + title="{Definitions of Managed Objects for IEEE 802.3 Repeater Devices}", + howpublished="RFC 1516 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1516", + pages="1--40", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2108", +url="https://www.rfc-editor.org/rfc/rfc1516.txt", + key="RFC 1516", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as ``hubs.'' [STANDARDS-TRACK]}, + keywords="Management, SNMP", + doi="10.17487/RFC1516", + } + +@misc{rfc1517, + author="Internet Engineering Steering Group and R. Hinden", + title="{Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)}", + howpublished="RFC 1517 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1517", + pages="1--4", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1517.txt", + key="RFC 1517", + abstract={Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]}, + keywords="CIDR, Address", + doi="10.17487/RFC1517", + } + +@misc{rfc1518, + author="Y. Rekhter and T. Li", + title="{An Architecture for IP Address Allocation with CIDR}", + howpublished="RFC 1518 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1518", + pages="1--27", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1518.txt", + key="RFC 1518", + abstract={This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]}, + keywords="CIDR-ARCH, Classless, Routing", + doi="10.17487/RFC1518", + } + +@misc{rfc1519, + author="V. Fuller and T. Li and J. Yu and K. Varadhan", + title="{Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy}", + howpublished="RFC 1519 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1519", + pages="1--24", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4632", +url="https://www.rfc-editor.org/rfc/rfc1519.txt", + key="RFC 1519", + abstract={This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK]}, + keywords="CIDR-STRA]", + doi="10.17487/RFC1519", + } + +@misc{rfc1520, + author="Y. Rekhter and C. Topolcic", + title="{Exchanging Routing Information Across Provider Boundaries in the CIDR Environment}", + howpublished="RFC 1520 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1520", + pages="1--9", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1520.txt", + key="RFC 1520", + abstract={The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Classless, Routing", + doi="10.17487/RFC1520", + } + +@misc{rfc1521, + author="N. Borenstein and N. Freed", + title="{MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies}", + howpublished="RFC 1521 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1521", + pages="1--81", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049, updated by RFC 1590", +url="https://www.rfc-editor.org/rfc/rfc1521.txt", + key="RFC 1521", + abstract={This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK]}, + keywords="email, multimedia", + doi="10.17487/RFC1521", + } + +@misc{rfc1522, + author="K. Moore", + title="{MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text}", + howpublished="RFC 1522 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1522", + pages="1--10", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049", +url="https://www.rfc-editor.org/rfc/rfc1522.txt", + key="RFC 1522", + abstract={This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.}, + keywords="email, character", + doi="10.17487/RFC1522", + } + +@misc{rfc1523, + author="N. Borenstein", + title="{The text/enriched MIME Content-type}", + howpublished="RFC 1523 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1523", + pages="1--15", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 1563, 1896", +url="https://www.rfc-editor.org/rfc/rfc1523.txt", + key="RFC 1523", + abstract={MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the ``text/richtext'' type defined in RFC 1341. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="email, mail, richtext", + doi="10.17487/RFC1523", + } + +@misc{rfc1524, + author="N. Borenstein", + title="{A User Agent Configuration Mechanism For Multimedia Mail Format Information}", + howpublished="RFC 1524 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1524", + pages="1--12", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1524.txt", + key="RFC 1524", + abstract={This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="MIME, email, mailcap", + doi="10.17487/RFC1524", + } + +@misc{rfc1525, + author="E. Decker and K. McCloghrie and P. Langille and A. Rijsinghani", + title="{Definitions of Managed Objects for Source Routing Bridges}", + howpublished="RFC 1525 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1525", + pages="1--18", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1525.txt", + key="RFC 1525", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]}, + keywords="SRB-MIB, MIB, Management, SNMP", + doi="10.17487/RFC1525", + } + +@misc{rfc1526, + author="D. Piscitello", + title="{Assignment of System Identifiers for TUBA/CLNP Hosts}", + howpublished="RFC 1526 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1526", + pages="1--8", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1526.txt", + key="RFC 1526", + abstract={This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="NSAP, Address", + doi="10.17487/RFC1526", + } + +@misc{rfc1527, + author="G. Cook", + title="{What Should We Plan Given the Dilemma of the Network?}", + howpublished="RFC 1527 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1527", + pages="1--17", + year=1993, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1527.txt", + key="RFC 1527", + abstract={The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make? This memo is a shortened version of the suggested policy draft. This memo provides information for the Internet community. It does not specify an Internet standard.}, + doi="10.17487/RFC1527", + } + +@misc{rfc1528, + author="C. Malamud and M. Rose", + title="{Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures}", + howpublished="RFC 1528 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1528", + pages="1--12", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1528.txt", + key="RFC 1528", + abstract={This memo describes a technique for ``remote printing'' using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.}, + keywords="REM-PRINT, FAX, Facsimile", + doi="10.17487/RFC1528", + } + +@misc{rfc1529, + author="C. Malamud and M. Rose", + title="{Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies}", + howpublished="RFC 1529 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1529", + pages="1--5", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1529.txt", + key="RFC 1529", + abstract={This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="FAX, Facsimile", + doi="10.17487/RFC1529", + } + +@misc{rfc1530, + author="C. Malamud and M. Rose", + title="{Principles of Operation for the TPC.INT Subdomain: General Principles and Policy}", + howpublished="RFC 1530 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1530", + pages="1--7", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1530.txt", + key="RFC 1530", + abstract={This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="FAX, Facsimile", + doi="10.17487/RFC1530", + } + +@misc{rfc1531, + author="R. Droms", + title="{Dynamic Host Configuration Protocol}", + howpublished="RFC 1531 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1531", + pages="1--39", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1541", +url="https://www.rfc-editor.org/rfc/rfc1531.txt", + key="RFC 1531", + abstract={The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK]}, + keywords="DHCP", + doi="10.17487/RFC1531", + } + +@misc{rfc1532, + author="W. Wimer", + title="{Clarifications and Extensions for the Bootstrap Protocol}", + howpublished="RFC 1532 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1532", + pages="1--22", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1542", +url="https://www.rfc-editor.org/rfc/rfc1532.txt", + key="RFC 1532", + abstract={Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of ``BOOTP relay agents'' (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]}, + keywords="BOOTP", + doi="10.17487/RFC1532", + } + +@misc{rfc1533, + author="S. Alexander and R. Droms", + title="{DHCP Options and BOOTP Vendor Extensions}", + howpublished="RFC 1533 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1533", + pages="1--30", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2132", +url="https://www.rfc-editor.org/rfc/rfc1533.txt", + key="RFC 1533", + abstract={This document specifies the current set of DHCP options. [STANDARDS-TRACK]}, + keywords="Dynamic, Host, Configuration, Bootstrap", + doi="10.17487/RFC1533", + } + +@misc{rfc1534, + author="R. Droms", + title="{Interoperation Between DHCP and BOOTP}", + howpublished="RFC 1534 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1534", + pages="1--4", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1534.txt", + key="RFC 1534", + abstract={DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK]}, + keywords="DHCP-BOOTP, Dynamic, Host, Configuration, Bootstrap", + doi="10.17487/RFC1534", + } + +@misc{rfc1535, + author="E. Gavron", + title="{A Security Problem and Proposed Correction With Widely Deployed DNS Software}", + howpublished="RFC 1535 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1535", + pages="1--5", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1535.txt", + key="RFC 1535", + abstract={This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit. This document points out the flaw, a case in point, and a solution. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Domain, Name, System", + doi="10.17487/RFC1535", + } + +@misc{rfc1536, + author="A. Kumar and J. Postel and C. Neuman and P. Danzig and S. Miller", + title="{Common DNS Implementation Errors and Suggested Fixes}", + howpublished="RFC 1536 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1536", + pages="1--12", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1536.txt", + key="RFC 1536", + abstract={This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Domain, Name, System", + doi="10.17487/RFC1536", + } + +@misc{rfc1537, + author="P. Beertema", + title="{Common DNS Data File Configuration Errors}", + howpublished="RFC 1537 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1537", + pages="1--9", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1912", +url="https://www.rfc-editor.org/rfc/rfc1537.txt", + key="RFC 1537", + abstract={This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Domain, Name, System", + doi="10.17487/RFC1537", + } + +@misc{rfc1538, + author="W. Behl and B. Sterling and W. Teskey", + title="{Advanced SNA/IP : A Simple SNA Transport Protocol}", + howpublished="RFC 1538 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1538", + pages="1--10", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1538.txt", + key="RFC 1538", + abstract={This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="ADSNA-IP, Domain, Name, System", + doi="10.17487/RFC1538", + } + +@misc{rfc1539, + author="G. Malkin", + title="{The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force}", + howpublished="RFC 1539 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1539", + pages="1--22", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1718", +url="https://www.rfc-editor.org/rfc/rfc1539.txt", + key="RFC 1539", + abstract={The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]}, + keywords="Introduction", + doi="10.17487/RFC1539", + } + +@misc{rfc1540, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1540 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1540", + pages="1--34", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1600", +url="https://www.rfc-editor.org/rfc/rfc1540.txt", + key="RFC 1540", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1540", + } + +@misc{rfc1541, + author="R. Droms", + title="{Dynamic Host Configuration Protocol}", + howpublished="RFC 1541 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1541", + pages="1--39", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2131", +url="https://www.rfc-editor.org/rfc/rfc1541.txt", + key="RFC 1541", + abstract={The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]}, + keywords="DHCP", + doi="10.17487/RFC1541", + } + +@misc{rfc1542, + author="W. Wimer", + title="{Clarifications and Extensions for the Bootstrap Protocol}", + howpublished="RFC 1542 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1542", + pages="1--23", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1542.txt", + key="RFC 1542", + abstract={Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of ``BOOTP relay agents'' (originally called ``BOOTP forwarding agents''). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]}, + keywords="BOOTP", + doi="10.17487/RFC1542", + } + +@misc{rfc1543, + author="J. Postel", + title="{Instructions to RFC Authors}", + howpublished="RFC 1543 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1543", + pages="1--16", + year=1993, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2223", +url="https://www.rfc-editor.org/rfc/rfc1543.txt", + key="RFC 1543", + abstract={This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Request, For, Comment", + doi="10.17487/RFC1543", + } + +@misc{rfc1544, + author="M. Rose", + title="{The Content-MD5 Header Field}", + howpublished="RFC 1544 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1544", + pages="1--3", + year=1993, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1864", +url="https://www.rfc-editor.org/rfc/rfc1544.txt", + key="RFC 1544", + abstract={This memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. [STANDARDS-TRACK]}, + keywords="MIME, EMail, Integrity, MIC, Digest", + doi="10.17487/RFC1544", + } + +@misc{rfc1545, + author="D. Piscitello", + title="{FTP Operation Over Big Address Records (FOOBAR)}", + howpublished="RFC 1545 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1545", + pages="1--5", + year=1993, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1639", +url="https://www.rfc-editor.org/rfc/rfc1545.txt", + key="RFC 1545", + abstract={This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). This is a general solution, applicable for all ``next generation'' IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="FTP, File Transfer, PORT, PASV, LPRT, LPSV", + doi="10.17487/RFC1545", + } + +@misc{rfc1546, + author="C. Partridge and T. Mendez and W. Milliken", + title="{Host Anycasting Service}", + howpublished="RFC 1546 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1546", + pages="1--9", + year=1993, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1546.txt", + key="RFC 1546", + abstract={This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Resource Location, Multicasting", + doi="10.17487/RFC1546", + } + +@misc{rfc1547, + author="D. Perkins", + title="{Requirements for an Internet Standard Point-to-Point Protocol}", + howpublished="RFC 1547 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1547", + pages="1--21", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1547.txt", + key="RFC 1547", + abstract={This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP, link, serial, line", + doi="10.17487/RFC1547", + } + +@misc{rfc1548, + author="W. Simpson", + title="{The Point-to-Point Protocol (PPP)}", + howpublished="RFC 1548 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1548", + pages="1--53", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1661, updated by RFC 1570", +url="https://www.rfc-editor.org/rfc/rfc1548.txt", + key="RFC 1548", + abstract={This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]}, + keywords="link, serial, line", + doi="10.17487/RFC1548", + } + +@misc{rfc1549, + author="W. {Simpson (Ed.)}", + title="{PPP in HDLC Framing}", + howpublished="RFC 1549 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1549", + pages="1--18", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1662", +url="https://www.rfc-editor.org/rfc/rfc1549.txt", + key="RFC 1549", + abstract={This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="point, link, serial, line", + doi="10.17487/RFC1549", + } + +@misc{rfc1550, + author="S. Bradner and A. Mankin", + title="{IP: Next Generation (IPng) White Paper Solicitation}", + howpublished="RFC 1550 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1550", + pages="1--6", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1550.txt", + key="RFC 1550", + abstract={This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1550", + } + +@misc{rfc1551, + author="M. Allen", + title="{Novell IPX Over Various WAN Media (IPXWAN)}", + howpublished="RFC 1551 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1551", + pages="1--22", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1634", +url="https://www.rfc-editor.org/rfc/rfc1551.txt", + key="RFC 1551", + abstract={This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common ``IPX WAN'' protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internetworking, Packet, Exchange", + doi="10.17487/RFC1551", + } + +@misc{rfc1552, + author="W. Simpson", + title="{The PPP Internetworking Packet Exchange Control Protocol (IPXCP)}", + howpublished="RFC 1552 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1552", + pages="1--16", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1552.txt", + key="RFC 1552", + abstract={This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK]}, + keywords="IPXCP, IPX, point, serial, line, link", + doi="10.17487/RFC1552", + } + +@misc{rfc1553, + author="S. Mathur and M. Lewis", + title="{Compressing IPX Headers Over WAN Media (CIPX)}", + howpublished="RFC 1553 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1553", + pages="1--23", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1553.txt", + key="RFC 1553", + abstract={This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK]}, + keywords="CIPX, Internetworking, Packet, Exchange", + doi="10.17487/RFC1553", + } + +@misc{rfc1554, + author="M. Ohta and K. Handa", + title="{ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP}", + howpublished="RFC 1554 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1554", + pages="1--6", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1554.txt", + key="RFC 1554", + abstract={This memo describes a text encoding scheme: ``ISO-2022-JP-2'', which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of ``ISO-2022-JP'', the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Character Set, Japanese", + doi="10.17487/RFC1554", + } + +@misc{rfc1555, + author="H. Nussbacher and Y. Bourvine", + title="{Hebrew Character Encoding for Internet Messages}", + howpublished="RFC 1555 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1555", + pages="1--5", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1555.txt", + key="RFC 1555", + abstract={This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME [RFC1521] and ISO-8859-8. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Character Set", + doi="10.17487/RFC1555", + } + +@misc{rfc1556, + author="H. Nussbacher", + title="{Handling of Bi-directional Texts in MIME}", + howpublished="RFC 1556 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1556", + pages="1--3", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1556.txt", + key="RFC 1556", + abstract={This document describes the format and syntax of the ``direction'' keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Character Set", + doi="10.17487/RFC1556", + } + +@misc{rfc1557, + author="U. Choi and K. Chon and H. Park", + title="{Korean Character Encoding for Internet Messages}", + howpublished="RFC 1557 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1557", + pages="1--5", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1557.txt", + key="RFC 1557", + abstract={This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Character Set", + doi="10.17487/RFC1557", + } + +@misc{rfc1558, + author="T. Howes", + title="{A String Representation of LDAP Search Filters}", + howpublished="RFC 1558 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1558", + pages="1--3", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1960", +url="https://www.rfc-editor.org/rfc/rfc1558.txt", + key="RFC 1558", + abstract={The Lightweight Directory Access Protocol (LDAP) defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="X.500, Directory", + doi="10.17487/RFC1558", + } + +@misc{rfc1559, + author="J. Saperia", + title="{DECnet Phase IV MIB Extensions}", + howpublished="RFC 1559 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1559", + pages="1--69", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1559.txt", + key="RFC 1559", + abstract={This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]}, + keywords="DECNET-MIB, Management, SNMP", + doi="10.17487/RFC1559", + } + +@misc{rfc1560, + author="B. Leiner and Y. Rekhter", + title="{The MultiProtocol Internet}", + howpublished="RFC 1560 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1560", + pages="1--7", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1560.txt", + key="RFC 1560", + abstract={There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Architecture, Protocol", + doi="10.17487/RFC1560", + } + +@misc{rfc1561, + author="D. Piscitello", + title="{Use of ISO CLNP in TUBA Environments}", + howpublished="RFC 1561 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1561", + pages="1--25", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1561.txt", + key="RFC 1561", + abstract={This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses. It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="CLNP-TUBA, OSI, IP, Internet, Protocol", + doi="10.17487/RFC1561", + } + +@misc{rfc1562, + author="G. Michaelson and M. Prior", + title="{Naming Guidelines for the AARNet X.500 Directory Service}", + howpublished="RFC 1562 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1562", + pages="1--4", + year=1993, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1562.txt", + key="RFC 1562", + abstract={This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001). AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Australia", + doi="10.17487/RFC1562", + } + +@misc{rfc1563, + author="N. Borenstein", + title="{The text/enriched MIME Content-type}", + howpublished="RFC 1563 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1563", + pages="1--16", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1896", +url="https://www.rfc-editor.org/rfc/rfc1563.txt", + key="RFC 1563", + abstract={MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the ``text/richtext'' type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="email, mail, richtext", + doi="10.17487/RFC1563", + } + +@misc{rfc1564, + author="P. Barker and R. Hedberg", + title="{DSA Metrics (OSI-DS 34 (v3))}", + howpublished="RFC 1564 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1564", + pages="1--21", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1564.txt", + key="RFC 1564", + abstract={This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="x.500, Directory, Service, Agent", + doi="10.17487/RFC1564", + } + +@misc{rfc1565, + author="S. Kille and N. Freed", + title="{Network Services Monitoring MIB}", + howpublished="RFC 1565 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1565", + pages="1--17", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2248", +url="https://www.rfc-editor.org/rfc/rfc1565.txt", + key="RFC 1565", + abstract={This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]}, + keywords="Management, Information, Base", + doi="10.17487/RFC1565", + } + +@misc{rfc1566, + author="S. Kille and N. Freed", + title="{Mail Monitoring MIB}", + howpublished="RFC 1566 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1566", + pages="1--20", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2249, 2789", +url="https://www.rfc-editor.org/rfc/rfc1566.txt", + key="RFC 1566", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]}, + keywords="Management, Information, Base", + doi="10.17487/RFC1566", + } + +@misc{rfc1567, + author="G. Mansfield and S. Kille", + title="{X.500 Directory Monitoring MIB}", + howpublished="RFC 1567 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1567", + pages="1--18", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2605", +url="https://www.rfc-editor.org/rfc/rfc1567.txt", + key="RFC 1567", + abstract={This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. [STANDARDS-TRACK]}, + keywords="X500-MIB, Management, Information, Base", + doi="10.17487/RFC1567", + } + +@misc{rfc1568, + author="A. Gwinn", + title="{Simple Network Paging Protocol - Version 1(b)}", + howpublished="RFC 1568 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1568", + pages="1--8", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1645", +url="https://www.rfc-editor.org/rfc/rfc1568.txt", + key="RFC 1568", + abstract={This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Beeper", + doi="10.17487/RFC1568", + } + +@misc{rfc1569, + author="M. Rose", + title="{Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures}", + howpublished="RFC 1569 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1569", + pages="1--6", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1703", +url="https://www.rfc-editor.org/rfc/rfc1569.txt", + key="RFC 1569", + abstract={This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Beeper", + doi="10.17487/RFC1569", + } + +@misc{rfc1570, + author="W. {Simpson (Ed.)}", + title="{PPP LCP Extensions}", + howpublished="RFC 1570 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1570", + pages="1--19", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2484", +url="https://www.rfc-editor.org/rfc/rfc1570.txt", + key="RFC 1570", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK]}, + keywords="PPP-LCP, Point-to Point, Link, Control, Protocol, serial, line", + doi="10.17487/RFC1570", + } + +@misc{rfc1571, + author="D. Borman", + title="{Telnet Environment Option Interoperability Issues}", + howpublished="RFC 1571 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1571", + pages="1--4", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1571.txt", + key="RFC 1571", + abstract={This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1571", + } + +@misc{rfc1572, + author="S. {Alexander (Ed.)}", + title="{Telnet Environment Option}", + howpublished="RFC 1572 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1572", + pages="1--7", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1572.txt", + key="RFC 1572", + abstract={This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. [STANDARDS-TRACK]}, + keywords="TOPT-ENVIR", + doi="10.17487/RFC1572", + } + +@misc{rfc1573, + author="K. McCloghrie and F. Kastenholz", + title="{Evolution of the Interfaces Group of MIB-II}", + howpublished="RFC 1573 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1573", + pages="1--55", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2233", +url="https://www.rfc-editor.org/rfc/rfc1573.txt", + key="RFC 1573", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK]}, + keywords="Management, Information, Base", + doi="10.17487/RFC1573", + } + +@misc{rfc1574, + author="S. Hares and C. Wittbrodt", + title="{Essential Tools for the OSI Internet}", + howpublished="RFC 1574 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1574", + pages="1--13", + year=1994, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1574.txt", + key="RFC 1574", + abstract={This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): ping or OSI Echo function, traceroute function which uses the OSI Echo function, and routing table dump function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Echo, Traceroute, Routing Table, CLNP", + doi="10.17487/RFC1574", + } + +@misc{rfc1575, + author="S. Hares and C. Wittbrodt", + title="{An Echo Function for CLNP (ISO 8473)}", + howpublished="RFC 1575 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1575", + pages="1--9", + year=1994, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1575.txt", + key="RFC 1575", + abstract={This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as ``Amendment X: Addition of an Echo function to ISO 8473'' an integral part of Version 2 of ISO 8473. [STANDARDS-TRACK]}, + keywords="ISO-TS-ECHO", + doi="10.17487/RFC1575", + } + +@misc{rfc1576, + author="J. Penner", + title="{TN3270 Current Practices}", + howpublished="RFC 1576 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1576", + pages="1--12", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1576.txt", + key="RFC 1576", + abstract={This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. This memo provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Telnet Option Terminal Type EOR Binary", + doi="10.17487/RFC1576", + } + +@misc{rfc1577, + author="M. Laubach", + title="{Classical IP and ARP over ATM}", + howpublished="RFC 1577 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1577", + pages="1--17", + year=1994, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2225", +url="https://www.rfc-editor.org/rfc/rfc1577.txt", + key="RFC 1577", + abstract={This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]}, + keywords="Internet, Protocol, Address, Resolution, Asynchronous, Transmission, Mode", + doi="10.17487/RFC1577", + } + +@misc{rfc1578, + author="J. Sellers", + title="{FYI on Questions and Answers - Answers to Commonly Asked ``Primary and Secondary School Internet User'' Questions}", + howpublished="RFC 1578 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1578", + pages="1--53", + year=1994, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1941", +url="https://www.rfc-editor.org/rfc/rfc1578.txt", + key="RFC 1578", + abstract={The goal of this FYI RFC is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 22]}, + keywords="K12", + doi="10.17487/RFC1578", + } + +@misc{rfc1579, + author="S. Bellovin", + title="{Firewall-Friendly FTP}", + howpublished="RFC 1579 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1579", + pages="1--4", + year=1994, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1579.txt", + key="RFC 1579", + abstract={This memo describes a suggested change to the behavior of FTP client programs. This document provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="file, transfer, PORT, PASV, Security", + doi="10.17487/RFC1579", + } + +@misc{rfc1580, + author="EARN Staff", + title="{Guide to Network Resource Tools}", + howpublished="RFC 1580 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1580", + pages="1--107", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1580.txt", + key="RFC 1580", + abstract={The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23]}, + keywords="EARN, BITNET, Gopher, World-Wide Web, WWW, WAIS, Archie, Whois, X.500, Netfind, Trickle, BIFTP, Listserv, Netnews, Astra, NetServ, Mail Base, Prospero, IRC, Relay", + doi="10.17487/RFC1580", + } + +@misc{rfc1581, + author="G. Meyer", + title="{Protocol Analysis for Extensions to RIP to Support Demand Circuits}", + howpublished="RFC 1581 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1581", + pages="1--4", + year=1994, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1581.txt", + key="RFC 1581", + abstract={As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="routing, Protocol", + doi="10.17487/RFC1581", + } + +@misc{rfc1582, + author="G. Meyer", + title="{Extensions to RIP to Support Demand Circuits}", + howpublished="RFC 1582 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1582", + pages="1--29", + year=1994, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1582.txt", + key="RFC 1582", + abstract={This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]}, + keywords="RIP-DC, routing, Protocol", + doi="10.17487/RFC1582", + } + +@misc{rfc1583, + author="J. Moy", + title="{OSPF Version 2}", + howpublished="RFC 1583 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1583", + pages="1--216", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2178", +url="https://www.rfc-editor.org/rfc/rfc1583.txt", + key="RFC 1583", + abstract={This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]}, + keywords="equal-cost, multipath, link state, LSA", + doi="10.17487/RFC1583", + } + +@misc{rfc1584, + author="J. Moy", + title="{Multicast Extensions to OSPF}", + howpublished="RFC 1584 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1584", + pages="1--102", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1584.txt", + key="RFC 1584", + abstract={This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]}, + keywords="OSPF-Multi, Open, Shortest, Path, First", + doi="10.17487/RFC1584", + } + +@misc{rfc1585, + author="J. Moy", + title="{MOSPF: Analysis and Experience}", + howpublished="RFC 1585 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1585", + pages="1--13", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1585.txt", + key="RFC 1585", + abstract={This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by ``Internet Engineering Task Force internet routing protocol standardization criteria'' ([RFC 1264]). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Multicast, Open, Shortest, Path, First, OSPF", + doi="10.17487/RFC1585", + } + +@misc{rfc1586, + author="O. deSouza and M. Rodrigues", + title="{Guidelines for Running OSPF Over Frame Relay Networks}", + howpublished="RFC 1586 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1586", + pages="1--6", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1586.txt", + key="RFC 1586", + abstract={This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="FR, Open, Shortest, Path, First", + doi="10.17487/RFC1586", + } + +@misc{rfc1587, + author="R. Coltun and V. Fuller", + title="{The OSPF NSSA Option}", + howpublished="RFC 1587 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1587", + pages="1--17", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3101", +url="https://www.rfc-editor.org/rfc/rfc1587.txt", + key="RFC 1587", + abstract={This document describes a new optional type of OSPF area, somewhat humorously referred to as a ``not-so-stubby'' area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]}, + keywords="OSPF-NSSA, Open, Shortest, Path, First, not so stubby, area, routing, protocol", + doi="10.17487/RFC1587", + } + +@misc{rfc1588, + author="J. Postel and C. Anderson", + title="{White Pages Meeting Report}", + howpublished="RFC 1588 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1588", + pages="1--35", + year=1994, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1588.txt", + key="RFC 1588", + abstract={This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="X-500 directory", + doi="10.17487/RFC1588", + } + +@misc{rfc1589, + author="D. Mills", + title="{A Kernel Model for Precision Timekeeping}", + howpublished="RFC 1589 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1589", + pages="1--37", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1589.txt", + key="RFC 1589", + abstract={This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Time, NTP, Clock", + doi="10.17487/RFC1589", + } + +@misc{rfc1590, + author="J. Postel", + title="{Media Type Registration Procedure}", + howpublished="RFC 1590 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1590", + pages="1--7", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049", +url="https://www.rfc-editor.org/rfc/rfc1590.txt", + key="RFC 1590", + abstract={Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="email, multimedia", + doi="10.17487/RFC1590", + } + +@misc{rfc1591, + author="J. Postel", + title="{Domain Name System Structure and Delegation}", + howpublished="RFC 1591 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1591", + pages="1--7", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1591.txt", + key="RFC 1591", + abstract={This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="DNS, Policy, Top-Level, TLD", + doi="10.17487/RFC1591", + } + +@misc{rfc1592, + author="B. Wijnen and G. Carpenter and K. Curran and A. Sehgal and G. Waters", + title="{Simple Network Management Protocol Distributed Protocol Interface Version 2.0}", + howpublished="RFC 1592 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1592", + pages="1--54", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1592.txt", + key="RFC 1592", + abstract={This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="SNMP-DPI, SNMP, DPT, IBM", + doi="10.17487/RFC1592", + } + +@misc{rfc1593, + author="W. McKenzie and J. Cheng", + title="{SNA APPN Node MIB}", + howpublished="RFC 1593 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1593", + pages="1--120", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1593.txt", + key="RFC 1593", + abstract={This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IBM, Management", + doi="10.17487/RFC1593", + } + +@misc{rfc1594, + author="A. Marine and J. Reynolds and G. Malkin", + title="{FYI on Questions and Answers - Answers to Commonly asked ``New Internet User'' Questions}", + howpublished="RFC 1594 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1594", + pages="1--44", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2664", +url="https://www.rfc-editor.org/rfc/rfc1594.txt", + key="RFC 1594", + abstract={This FYI RFC is one of two FYI's called, ``Questions and Answers'' (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 4]}, + keywords="documentation, help, information, FAQ", + doi="10.17487/RFC1594", + } + +@misc{rfc1595, + author="T. Brown and K. Tesink", + title="{Definitions of Managed Objects for the SONET/SDH Interface Type}", + howpublished="RFC 1595 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1595", + pages="1--59", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2558", +url="https://www.rfc-editor.org/rfc/rfc1595.txt", + key="RFC 1595", + keywords="SONET-MIB, MIB, Management, SNMP", + doi="10.17487/RFC1595", + } + +@misc{rfc1596, + author="T. {Brown (Ed.)}", + title="{Definitions of Managed Objects for Frame Relay Service}", + howpublished="RFC 1596 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1596", + pages="1--46", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1604", +url="https://www.rfc-editor.org/rfc/rfc1596.txt", + key="RFC 1596", + keywords="FR, MIB, Management, SNMP", + doi="10.17487/RFC1596", + } + +@misc{rfc1597, + author="Y. Rekhter and B. Moskowitz and D. Karrenberg and G. de Groot", + title="{Address Allocation for Private Internets}", + howpublished="RFC 1597 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1597", + pages="1--8", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1918", +url="https://www.rfc-editor.org/rfc/rfc1597.txt", + key="RFC 1597", + abstract={This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, Network, Number, Local", + doi="10.17487/RFC1597", + } + +@misc{rfc1598, + author="W. Simpson", + title="{PPP in X.25}", + howpublished="RFC 1598 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1598", + pages="1--8", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1598.txt", + key="RFC 1598", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="PPP-X25, point", + doi="10.17487/RFC1598", + } + +@misc{rfc1599, + author="M. Kennedy", + title="{Summary of 1500-1599}", + howpublished="RFC 1599 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1599", + pages="1--22", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1599.txt", + key="RFC 1599", + keywords="Index", + doi="10.17487/RFC1599", + } + +@misc{rfc1600, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1600 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1600", + pages="1--36", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1610", +url="https://www.rfc-editor.org/rfc/rfc1600.txt", + key="RFC 1600", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1600", + } + +@misc{rfc1601, + author="C. Huitema", + title="{Charter of the Internet Architecture Board (IAB)}", + howpublished="RFC 1601 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1601", + pages="1--6", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2850", +url="https://www.rfc-editor.org/rfc/rfc1601.txt", + key="RFC 1601", + abstract={This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="ISOC, Internet Society, IETF, IRTF", + doi="10.17487/RFC1601", + } + +@misc{rfc1602, + author="Internet Architecture Board and Internet Engineering Steering Group", + title="{The Internet Standards Process -- Revision 2}", + howpublished="RFC 1602 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1602", + pages="1--37", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2026, updated by RFC 1871", +url="https://www.rfc-editor.org/rfc/rfc1602.txt", + key="RFC 1602", + abstract={This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1602", + } + +@misc{rfc1603, + author="E. Huizer and D. Crocker", + title="{IETF Working Group Guidelines and Procedures}", + howpublished="RFC 1603 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1603", + pages="1--29", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2418, updated by RFC 1871", +url="https://www.rfc-editor.org/rfc/rfc1603.txt", + key="RFC 1603", + abstract={This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="WG", + doi="10.17487/RFC1603", + } + +@misc{rfc1604, + author="T. {Brown (Ed.)}", + title="{Definitions of Managed Objects for Frame Relay Service}", + howpublished="RFC 1604 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1604", + pages="1--46", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2954", +url="https://www.rfc-editor.org/rfc/rfc1604.txt", + key="RFC 1604", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]}, + keywords="FR-MIB, MIB, Management, SNMP, Network", + doi="10.17487/RFC1604", + } + +@misc{rfc1605, + author="W. Shakespeare", + title="{SONET to Sonnet Translation}", + howpublished="RFC 1605 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1605", + pages="1--3", + year=1994, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1605.txt", + key="RFC 1605", + abstract={Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation (SONNET). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Humor", + doi="10.17487/RFC1605", + } + +@misc{rfc1606, + author="J. Onions", + title="{A Historical Perspective On The Usage Of IP Version 9}", + howpublished="RFC 1606 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1606", + pages="1--4", + year=1994, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1606.txt", + key="RFC 1606", + abstract={This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Humor", + doi="10.17487/RFC1606", + } + +@misc{rfc1607, + author="V. Cerf", + title="{A VIEW FROM THE 21ST CENTURY}", + howpublished="RFC 1607 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1607", + pages="1--14", + year=1994, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1607.txt", + key="RFC 1607", + abstract={This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="V. Cerf", + doi="10.17487/RFC1607", + } + +@misc{rfc1608, + author="T. Johannsen and G. Mansfield and M. Kosters and S. Sataluri", + title="{Representing IP Information in the X.500 Directory}", + howpublished="RFC 1608 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1608", + pages="1--20", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1608.txt", + key="RFC 1608", + abstract={This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work ``Charting networks in the X.500 Directory'' [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks. This memo defines an Experimental Protocol for the Internet community.}, + keywords="X500-DIR, Data, Structure, Schemo", + doi="10.17487/RFC1608", + } + +@misc{rfc1609, + author="G. Mansfield and T. Johannsen and M. Knopper", + title="{Charting Networks in the X.500 Directory}", + howpublished="RFC 1609 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1609", + pages="1--15", + year=1994, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1609.txt", + key="RFC 1609", + abstract={This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. This memo defines an Experimental Protocol for the Internet community.}, + keywords="X500-CHART, Data, Structure, Schemo", + doi="10.17487/RFC1609", + } + +@misc{rfc1610, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1610 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1610", + pages="1--36", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1720", +url="https://www.rfc-editor.org/rfc/rfc1610.txt", + key="RFC 1610", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1610", + } + +@misc{rfc1611, + author="R. Austein and J. Saperia", + title="{DNS Server MIB Extensions}", + howpublished="RFC 1611 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1611", + pages="1--30", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1611.txt", + key="RFC 1611", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]}, + keywords="DNS-S-MIB, Domain, Name, System, Management, Information, Base", + doi="10.17487/RFC1611", + } + +@misc{rfc1612, + author="R. Austein and J. Saperia", + title="{DNS Resolver MIB Extensions}", + howpublished="RFC 1612 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1612", + pages="1--32", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1612.txt", + key="RFC 1612", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]}, + keywords="DNS-R-MIB, Domain, Name, System, Management, Information, Base", + doi="10.17487/RFC1612", + } + +@misc{rfc1613, + author="J. Forster and G. Satz and G. Glick and R. Day", + title="{cisco Systems X.25 over TCP (XOT)}", + howpublished="RFC 1613 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1613", + pages="1--13", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1613.txt", + key="RFC 1613", + abstract={This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Transmission, Control, Protocol", + doi="10.17487/RFC1613", + } + +@misc{rfc1614, + author="C. Adie", + title="{Network Access to Multimedia Information}", + howpublished="RFC 1614 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1614", + pages="1--79", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1614.txt", + key="RFC 1614", + abstract={This report summarises the requirements of research and academic network users for network access to multimedia information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RARE, Technical, Report", + doi="10.17487/RFC1614", + } + +@misc{rfc1615, + author="J. Houttuin and J. Craigie", + title="{Migrating from X.400(84) to X.400(88)}", + howpublished="RFC 1615 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1615", + pages="1--17", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1615.txt", + key="RFC 1615", + abstract={This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RARE, Technical, Report, email", + doi="10.17487/RFC1615", + } + +@misc{rfc1616, + author="RARE WG-MSG Task Force 88 and E. {Huizer (Ed.)} and J. {Romaguera (Ed.)}", + title="{X.400(1988) for the Academic and Research Community in Europe}", + howpublished="RFC 1616 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1616", + pages="1--44", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1616.txt", + key="RFC 1616", + abstract={The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RARE, Technical, Report, email", + doi="10.17487/RFC1616", + } + +@misc{rfc1617, + author="P. Barker and S. Kille and T. Lenggenhager", + title="{Naming and Structuring Guidelines for X.500 Directory Pilots}", + howpublished="RFC 1617 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1617", + pages="1--28", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1617.txt", + key="RFC 1617", + abstract={This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RARE, Technical, Report, White Pages", + doi="10.17487/RFC1617", + } + +@misc{rfc1618, + author="W. Simpson", + title="{PPP over ISDN}", + howpublished="RFC 1618 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1618", + pages="1--7", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1618.txt", + key="RFC 1618", + abstract={This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]}, + keywords="PPP-ISDN, Point, Integrated Services Digital Network", + doi="10.17487/RFC1618", + } + +@misc{rfc1619, + author="W. Simpson", + title="{PPP over SONET/SDH}", + howpublished="RFC 1619 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1619", + pages="1--5", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2615", +url="https://www.rfc-editor.org/rfc/rfc1619.txt", + key="RFC 1619", + abstract={This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS-TRACK]}, + keywords="PPP-SONET, Point, Synchronous Optical Network Digital Heirarchy", + doi="10.17487/RFC1619", + } + +@misc{rfc1620, + author="B. Braden and J. Postel and Y. Rekhter", + title="{Internet Architecture Extensions for Shared Media}", + howpublished="RFC 1620 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1620", + pages="1--19", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1620.txt", + key="RFC 1620", + abstract={This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Public, data, networks, ARP, address, resolution, protocol", + doi="10.17487/RFC1620", + } + +@misc{rfc1621, + author="P. Francis", + title="{Pip Near-term Architecture}", + howpublished="RFC 1621 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1621", + pages="1--51", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1621.txt", + key="RFC 1621", + abstract={The purpose of this RFC and the companion RFC ``Pip Header Processing'' are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet Protocol, IPng", + doi="10.17487/RFC1621", + } + +@misc{rfc1622, + author="P. Francis", + title="{Pip Header Processing}", + howpublished="RFC 1622 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1622", + pages="1--16", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1622.txt", + key="RFC 1622", + abstract={The purpose of this RFC and the companion RFC ``Pip Near-term Architecture'' are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet Protocol, IPng", + doi="10.17487/RFC1622", + } + +@misc{rfc1623, + author="F. Kastenholz", + title="{Definitions of Managed Objects for the Ethernet-like Interface Types}", + howpublished="RFC 1623 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1623", + pages="1--19", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1643", +url="https://www.rfc-editor.org/rfc/rfc1623.txt", + key="RFC 1623", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]}, + keywords="MIB, Management, Information, Base", + doi="10.17487/RFC1623", + } + +@misc{rfc1624, + author="A. {Rijsinghani (Ed.)}", + title="{Computation of the Internet Checksum via Incremental Update}", + howpublished="RFC 1624 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1624", + pages="1--6", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1624.txt", + key="RFC 1624", + abstract={This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1624", + } + +@misc{rfc1625, + author="M. St. Pierre and J. Fullton and K. Gamiel and J. Goldman and B. Kahle and J. Kunze and H. Morris and F. Schiettecatte", + title="{WAIS over Z39.50-1988}", + howpublished="RFC 1625 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1625", + pages="1--7", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1625.txt", + key="RFC 1625", + abstract={The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Wide, Area, Information, Servers, Library", + doi="10.17487/RFC1625", + } + +@misc{rfc1626, + author="R. Atkinson", + title="{Default IP MTU for use over ATM AAL5}", + howpublished="RFC 1626 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1626", + pages="1--5", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2225", +url="https://www.rfc-editor.org/rfc/rfc1626.txt", + key="RFC 1626", + abstract={There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]}, + keywords="Maximum, Transmission, Unit, Asynchronous, Transfer, Mode, Adaptation, Layer, Size, Packet", + doi="10.17487/RFC1626", + } + +@misc{rfc1627, + author="E. Lear and E. Fair and D. Crocker and T. Kessler", + title="{Network 10 Considered Harmful (Some Practices Shouldn't be Codified)}", + howpublished="RFC 1627 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1627", + pages="1--8", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1918", +url="https://www.rfc-editor.org/rfc/rfc1627.txt", + key="RFC 1627", + abstract={This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, Network, Number, Local", + doi="10.17487/RFC1627", + } + +@misc{rfc1628, + author="J. {Case (Ed.)}", + title="{UPS Management Information Base}", + howpublished="RFC 1628 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1628", + pages="1--45", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1628.txt", + key="RFC 1628", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]}, + keywords="UPS-MIB, Uninterruptible, Power, Supply, MIB", + doi="10.17487/RFC1628", + } + +@misc{rfc1629, + author="R. Colella and R. Callon and E. Gardner and Y. Rekhter", + title="{Guidelines for OSI NSAP Allocation in the Internet}", + howpublished="RFC 1629 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1629", + pages="1--52", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1629.txt", + key="RFC 1629", + abstract={This paper provides guidelines for allocating NSAP addresses in the Internet. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK]}, + keywords="OSI-NSAP, CLNP, Address", + doi="10.17487/RFC1629", + } + +@misc{rfc1630, + author="T. Berners-Lee", + 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}", + howpublished="RFC 1630 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1630", + pages="1--28", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1630.txt", + key="RFC 1630", + abstract={This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="World, Wide, Web, URI", + doi="10.17487/RFC1630", + } + +@misc{rfc1631, + author="K. Egevang and P. Francis", + title="{The IP Network Address Translator (NAT)}", + howpublished="RFC 1631 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1631", + pages="1--10", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3022", +url="https://www.rfc-editor.org/rfc/rfc1631.txt", + key="RFC 1631", + abstract={This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet Protocol", + doi="10.17487/RFC1631", + } + +@misc{rfc1632, + author="A. {Getchell (Ed.)} and S. {Sataluri (Ed.)}", + title="{A Revised Catalog of Available X.500 Implementations}", + howpublished="RFC 1632 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1632", + pages="1--94", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2116", +url="https://www.rfc-editor.org/rfc/rfc1632.txt", + key="RFC 1632", + abstract={This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Directory, White, Pages", + doi="10.17487/RFC1632", + } + +@misc{rfc1633, + author="R. Braden and D. Clark and S. Shenker", + title="{Integrated Services in the Internet Architecture: an Overview}", + howpublished="RFC 1633 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1633", + pages="1--33", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1633.txt", + key="RFC 1633", + abstract={This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="real time, Multi-media, reservations, Protocol", + doi="10.17487/RFC1633", + } + +@misc{rfc1634, + author="M. Allen", + title="{Novell IPX Over Various WAN Media (IPXWAN)}", + howpublished="RFC 1634 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1634", + pages="1--23", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1634.txt", + key="RFC 1634", + abstract={This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common ``IPX WAN'' protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="wide, area, network", + doi="10.17487/RFC1634", + } + +@misc{rfc1635, + author="P. Deutsch and A. Emtage and A. Marine", + title="{How to Use Anonymous FTP}", + howpublished="RFC 1635 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1635", + pages="1--13", + year=1994, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1635.txt", + key="RFC 1635", + abstract={This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="File, Transfer, Protocol", + doi="10.17487/RFC1635", + } + +@misc{rfc1636, + author="R. Braden and D. Clark and S. Crocker and C. Huitema", + title="{Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994}", + howpublished="RFC 1636 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1636", + pages="1--52", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1636.txt", + key="RFC 1636", + abstract={This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Architecture, Board", + doi="10.17487/RFC1636", + } + +@misc{rfc1637, + author="B. Manning and R. Colella", + title="{DNS NSAP Resource Records}", + howpublished="RFC 1637 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1637", + pages="1--11", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1706", +url="https://www.rfc-editor.org/rfc/rfc1637.txt", + key="RFC 1637", + abstract={This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. This memo defines an Experimental Protocol for the Internet community.}, + keywords="domain, Name, System, ISO, OSI, Address", + doi="10.17487/RFC1637", + } + +@misc{rfc1638, + author="F. Baker and R. Bowen", + title="{PPP Bridging Control Protocol (BCP)}", + howpublished="RFC 1638 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1638", + pages="1--28", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2878", +url="https://www.rfc-editor.org/rfc/rfc1638.txt", + key="RFC 1638", + abstract={This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]}, + keywords="PPP-BCP, Point to Point", + doi="10.17487/RFC1638", + } + +@misc{rfc1639, + author="D. Piscitello", + title="{FTP Operation Over Big Address Records (FOOBAR)}", + howpublished="RFC 1639 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1639", + pages="1--5", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1639.txt", + key="RFC 1639", + abstract={This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a ``long Port (LPRT)'' command and ``Long Passive (LPSV)'' reply, each having as its argument a <long-host-port>, 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.}, + keywords="FOOBAR, File, Transfer, Port", + doi="10.17487/RFC1639", + } + +@misc{rfc1640, + author="S. Crocker", + title="{The Process for Organization of Internet Standards Working Group (POISED)}", + howpublished="RFC 1640 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1640", + pages="1--10", + year=1994, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1640.txt", + key="RFC 1640", + abstract={This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IETF, IESG, IAB, ISOC", + doi="10.17487/RFC1640", + } + +@misc{rfc1641, + author="D. Goldsmith and M. Davis", + title="{Using Unicode with MIME}", + howpublished="RFC 1641 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1641", + pages="1--6", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1641.txt", + key="RFC 1641", + abstract={This document specifies the usage of Unicode within MIME. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MIME-UNI, Multipurpose, Internet, Mail, Extension, Character, Set", + doi="10.17487/RFC1641", + } + +@misc{rfc1642, + author="D. Goldsmith and M. Davis", + title="{UTF-7 - A Mail-Safe Transformation Format of Unicode}", + howpublished="RFC 1642 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1642", + pages="1--14", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2152", +url="https://www.rfc-editor.org/rfc/rfc1642.txt", + key="RFC 1642", + abstract={This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. This memo defines an Experimental Protocol for the Internet community.}, + keywords="character, Set", + doi="10.17487/RFC1642", + } + +@misc{rfc1643, + author="F. Kastenholz", + title="{Definitions of Managed Objects for the Ethernet-like Interface Types}", + howpublished="RFC 1643 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1643", + pages="1--19", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3638", +url="https://www.rfc-editor.org/rfc/rfc1643.txt", + key="RFC 1643", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]}, + keywords="ETHER-MIB, MIB, Network, Management, SNMP, Ethernet", + doi="10.17487/RFC1643", + } + +@misc{rfc1644, + author="R. Braden", + title="{T/TCP -- TCP Extensions for Transactions Functional Specification}", + howpublished="RFC 1644 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1644", + pages="1--38", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6247", +url="https://www.rfc-editor.org/rfc/rfc1644.txt", + key="RFC 1644", + abstract={This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This memo describes an Experimental Protocol for the Internet community.}, + keywords="T/TCP, Transmission, Control, Protocol", + doi="10.17487/RFC1644", + } + +@misc{rfc1645, + author="A. Gwinn", + title="{Simple Network Paging Protocol - Version 2}", + howpublished="RFC 1645 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1645", + pages="1--15", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1861", +url="https://www.rfc-editor.org/rfc/rfc1645.txt", + key="RFC 1645", + abstract={This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Beeper, SNPP, Mail", + doi="10.17487/RFC1645", + } + +@misc{rfc1646, + author="C. Graves and T. Butts and M. Angel", + title="{TN3270 Extensions for LUname and Printer Selection}", + howpublished="RFC 1646 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1646", + pages="1--13", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1646.txt", + key="RFC 1646", + abstract={This document describes protocol extensions to TN3270. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Telnet, Option", + doi="10.17487/RFC1646", + } + +@misc{rfc1647, + author="B. Kelly", + title="{TN3270 Enhancements}", + howpublished="RFC 1647 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1647", + pages="1--34", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2355", +url="https://www.rfc-editor.org/rfc/rfc1647.txt", + key="RFC 1647", + abstract={This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK]}, + keywords="Telnet, Option", + doi="10.17487/RFC1647", + } + +@misc{rfc1648, + author="A. Cargille", + title="{Postmaster Convention for X.400 Operations}", + howpublished="RFC 1648 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1648", + pages="1--4", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1648.txt", + key="RFC 1648", + abstract={This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. [STANDARDS-TRACK]}, + keywords="Mail", + doi="10.17487/RFC1648", + } + +@misc{rfc1649, + author="R. Hagens and A. Hansen", + title="{Operational Requirements for X.400 Management Domains in the GO-MHS Community}", + howpublished="RFC 1649 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1649", + pages="1--14", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1649.txt", + key="RFC 1649", + abstract={The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Mail, Global, Open, Message, Handling, System", + doi="10.17487/RFC1649", + } + +@misc{rfc1650, + author="F. Kastenholz", + title="{Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2}", + howpublished="RFC 1650 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1650", + pages="1--20", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2358", +url="https://www.rfc-editor.org/rfc/rfc1650.txt", + key="RFC 1650", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]}, + keywords="MIB, Management, Information, Base, 802.3", + doi="10.17487/RFC1650", + } + +@misc{rfc1651, + author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker", + title="{SMTP Service Extensions}", + howpublished="RFC 1651 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1651", + pages="1--11", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1869", +url="https://www.rfc-editor.org/rfc/rfc1651.txt", + key="RFC 1651", + abstract={This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]}, + keywords="Mail, Simple, Transfer", + doi="10.17487/RFC1651", + } + +@misc{rfc1652, + author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker", + title="{SMTP Service Extension for 8bit-MIMEtransport}", + howpublished="RFC 1652 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1652", + pages="1--6", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6152", +url="https://www.rfc-editor.org/rfc/rfc1652.txt", + key="RFC 1652", + abstract={This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]}, + keywords="SMTP, Mail, Simple, Transfer", + doi="10.17487/RFC1652", + } + +@misc{rfc1653, + author="J. Klensin and N. Freed and K. Moore", + title="{SMTP Service Extension for Message Size Declaration}", + howpublished="RFC 1653 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1653", + pages="1--8", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1870", +url="https://www.rfc-editor.org/rfc/rfc1653.txt", + key="RFC 1653", + abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]}, + keywords="Mail, Simple, Transfer, Protocol", + doi="10.17487/RFC1653", + } + +@misc{rfc1654, + author="Y. {Rekhter (Ed.)} and T. {Li (Ed.)}", + title="{A Border Gateway Protocol 4 (BGP-4)}", + howpublished="RFC 1654 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1654", + pages="1--56", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1771", +url="https://www.rfc-editor.org/rfc/rfc1654.txt", + key="RFC 1654", + abstract={This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]}, + keywords="routing", + doi="10.17487/RFC1654", + } + +@misc{rfc1655, + author="Y. {Rekhter (Ed.)} and P. {Gross (Ed.)}", + title="{Application of the Border Gateway Protocol in the Internet}", + howpublished="RFC 1655 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1655", + pages="1--19", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1772", +url="https://www.rfc-editor.org/rfc/rfc1655.txt", + key="RFC 1655", + abstract={This document, together with its companion document, ``A Border Gateway Protocol 4 (BGP-4)'', define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]}, + keywords="BGP-4, Routing", + doi="10.17487/RFC1655", + } + +@misc{rfc1656, + author="P. Traina", + title="{BGP-4 Protocol Document Roadmap and Implementation Experience}", + howpublished="RFC 1656 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1656", + pages="1--4", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1773", +url="https://www.rfc-editor.org/rfc/rfc1656.txt", + key="RFC 1656", + abstract={Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Border, Gateway, Protocol, Routing", + doi="10.17487/RFC1656", + } + +@misc{rfc1657, + author="S. Willis and J. Burruss and J. {Chu (Ed.)}", + title="{Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2}", + howpublished="RFC 1657 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1657", + pages="1--21", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4273", +url="https://www.rfc-editor.org/rfc/rfc1657.txt", + key="RFC 1657", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]}, + keywords="BGP-4-MIB, MIB, Management, Information, Base", + doi="10.17487/RFC1657", + } + +@misc{rfc1658, + author="B. Stewart", + title="{Definitions of Managed Objects for Character Stream Devices using SMIv2}", + howpublished="RFC 1658 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1658", + pages="1--18", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1658.txt", + key="RFC 1658", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]}, + keywords="MIB, Network, Management, Base", + doi="10.17487/RFC1658", + } + +@misc{rfc1659, + author="B. Stewart", + title="{Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2}", + howpublished="RFC 1659 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1659", + pages="1--21", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1659.txt", + key="RFC 1659", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]}, + keywords="MIB, Network, Management, Base", + doi="10.17487/RFC1659", + } + +@misc{rfc1660, + author="B. Stewart", + title="{Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2}", + howpublished="RFC 1660 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1660", + pages="1--10", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1660.txt", + key="RFC 1660", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]}, + keywords="MIB, Network, Management, Base", + doi="10.17487/RFC1660", + } + +@misc{rfc1661, + author="W. {Simpson (Ed.)}", + title="{The Point-to-Point Protocol (PPP)}", + howpublished="RFC 1661 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1661", + pages="1--53", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2153", +url="https://www.rfc-editor.org/rfc/rfc1661.txt", + key="RFC 1661", + abstract={This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]}, + keywords="PPP, Specification, Standard, link, serial, line", + doi="10.17487/RFC1661", + } + +@misc{rfc1662, + author="W. {Simpson (Ed.)}", + title="{PPP in HDLC-like Framing}", + howpublished="RFC 1662 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1662", + pages="1--26", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1662.txt", + key="RFC 1662", + abstract={This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="PPP-HDLC, Point, Protocol, Specification, Standard, link, serial, line", + doi="10.17487/RFC1662", + } + +@misc{rfc1663, + author="D. Rand", + title="{PPP Reliable Transmission}", + howpublished="RFC 1663 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1663", + pages="1--8", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1663.txt", + key="RFC 1663", + abstract={This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. [STANDARDS-TRACK]}, + keywords="PPP-TRANS, Point, Protocol", + doi="10.17487/RFC1663", + } + +@misc{rfc1664, + author="C. Allocchio and A. Bonito and B. Cole and S. Giordano and R. Hagens", + title="{Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables}", + howpublished="RFC 1664 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1664", + pages="1--23", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2163", +url="https://www.rfc-editor.org/rfc/rfc1664.txt", + key="RFC 1664", + abstract={This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. This memo defines an Experimental Protocol for the Internet community.}, + keywords="domain, Name, System, X.400, Email", + doi="10.17487/RFC1664", + } + +@misc{rfc1665, + author="Z. {Kielczewski (Ed.)} and D. {Kostick (Ed.)} and K. {Shih (Ed.)}", + title="{Definitions of Managed Objects for SNA NAUs using SMIv2}", + howpublished="RFC 1665 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1665", + pages="1--67", + year=1994, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1666", +url="https://www.rfc-editor.org/rfc/rfc1665.txt", + key="RFC 1665", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]}, + keywords="MIB, Management, Information, Base, System, Network, Architecture, Addressable, Units", + doi="10.17487/RFC1665", + } + +@misc{rfc1666, + author="Z. {Kielczewski (Ed.)} and D. {Kostick (Ed.)} and K. {Shih (Ed.)}", + title="{Definitions of Managed Objects for SNA NAUs using SMIv2}", + howpublished="RFC 1666 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1666", + pages="1--68", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1666.txt", + key="RFC 1666", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]}, + keywords="SNANAU-MIB, Network, Management, SNMP, MIB, Protocol, Units, Architecture, Addressable, Information, System", + doi="10.17487/RFC1666", + } + +@misc{rfc1667, + author="S. Symington and D. Wood and M. Pullen", + title="{Modeling and Simulation Requirements for IPng}", + howpublished="RFC 1667 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1667", + pages="1--7", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1667.txt", + key="RFC 1667", + abstract={This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1667", + } + +@misc{rfc1668, + author="D. Estrin and T. Li and Y. Rekhter", + title="{Unified Routing Requirements for IPng}", + howpublished="RFC 1668 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1668", + pages="1--3", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1668.txt", + key="RFC 1668", + abstract={The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1668", + } + +@misc{rfc1669, + author="J. Curran", + title="{Market Viability as a IPng Criteria}", + howpublished="RFC 1669 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1669", + pages="1--4", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1669.txt", + key="RFC 1669", + abstract={``Viability in the Marketplace'' is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1669", + } + +@misc{rfc1670, + author="D. Heagerty", + title="{Input to IPng Engineering Considerations}", + howpublished="RFC 1670 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1670", + pages="1--3", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1670.txt", + key="RFC 1670", + abstract={This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition. It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1670", + } + +@misc{rfc1671, + author="B. Carpenter", + title="{IPng White Paper on Transition and Other Considerations}", + howpublished="RFC 1671 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1671", + pages="1--8", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1671.txt", + key="RFC 1671", + abstract={This white paper outlines some general requirements for IPng in selected areas. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1671", + } + +@misc{rfc1672, + author="N. Brownlee", + title="{Accounting Requirements for IPng}", + howpublished="RFC 1672 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1672", + pages="1--3", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1672.txt", + key="RFC 1672", + abstract={This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1672", + } + +@misc{rfc1673, + author="R. Skelton", + title="{Electric Power Research Institute Comments on IPng}", + howpublished="RFC 1673 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1673", + pages="1--4", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1673.txt", + key="RFC 1673", + abstract={This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1673", + } + +@misc{rfc1674, + author="M. Taylor", + title="{A Cellular Industry View of IPng}", + howpublished="RFC 1674 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1674", + pages="1--3", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1674.txt", + key="RFC 1674", + abstract={This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1674", + } + +@misc{rfc1675, + author="S. Bellovin", + title="{Security Concerns for IPng}", + howpublished="RFC 1675 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1675", + pages="1--4", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1675.txt", + key="RFC 1675", + abstract={A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1675", + } + +@misc{rfc1676, + author="A. Ghiselli and D. Salomoni and C. Vistoli", + title="{INFN Requirements for an IPng}", + howpublished="RFC 1676 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1676", + pages="1--4", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1676.txt", + key="RFC 1676", + abstract={With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1676", + } + +@misc{rfc1677, + author="B. Adamson", + title="{Tactical Radio Frequency Communication Requirements for IPng}", + howpublished="RFC 1677 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1677", + pages="1--9", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1677.txt", + key="RFC 1677", + abstract={This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1677", + } + +@misc{rfc1678, + author="E. Britton and J. Tavs", + title="{IPng Requirements of Large Corporate Networks}", + howpublished="RFC 1678 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1678", + pages="1--8", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1678.txt", + key="RFC 1678", + abstract={This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1678", + } + +@misc{rfc1679, + author="D. Green and P. Irey and D. Marlow and K. O'Donoghue", + title="{HPN Working Group Input to the IPng Requirements Solicitation}", + howpublished="RFC 1679 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1679", + pages="1--10", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1679.txt", + key="RFC 1679", + abstract={The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1679", + } + +@misc{rfc1680, + author="C. Brazdziunas", + title="{IPng Support for ATM Services}", + howpublished="RFC 1680 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1680", + pages="1--7", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1680.txt", + key="RFC 1680", + abstract={This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1680", + } + +@misc{rfc1681, + author="S. Bellovin", + title="{On Many Addresses per Host}", + howpublished="RFC 1681 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1681", + pages="1--5", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1681.txt", + key="RFC 1681", + abstract={This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1681", + } + +@misc{rfc1682, + author="J. Bound", + title="{IPng BSD Host Implementation Analysis}", + howpublished="RFC 1682 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1682", + pages="1--10", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1682.txt", + key="RFC 1682", + abstract={This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper, Unix", + doi="10.17487/RFC1682", + } + +@misc{rfc1683, + author="R. Clark and M. Ammar and K. Calvert", + title="{Multiprotocol Interoperability In IPng}", + howpublished="RFC 1683 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1683", + pages="1--12", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1683.txt", + key="RFC 1683", + abstract={In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1683", + } + +@misc{rfc1684, + author="P. Jurg", + title="{Introduction to White Pages Services based on X.500}", + howpublished="RFC 1684 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1684", + pages="1--10", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1684.txt", + key="RFC 1684", + abstract={The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Directory", + doi="10.17487/RFC1684", + } + +@misc{rfc1685, + author="H. Alvestrand", + title="{Writing X.400 O/R Names}", + howpublished="RFC 1685 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1685", + pages="1--11", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1685.txt", + key="RFC 1685", + abstract={There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind.}, + keywords="EMail, Mail", + doi="10.17487/RFC1685", + } + +@misc{rfc1686, + author="M. Vecchi", + title="{IPng Requirements: A Cable Television Industry Viewpoint}", + howpublished="RFC 1686 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1686", + pages="1--14", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1686.txt", + key="RFC 1686", + abstract={This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1686", + } + +@misc{rfc1687, + author="E. Fleischman", + title="{A Large Corporate User's View of IPng}", + howpublished="RFC 1687 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1687", + pages="1--13", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1687.txt", + key="RFC 1687", + abstract={The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1687", + } + +@misc{rfc1688, + author="W. Simpson", + title="{IPng Mobility Considerations}", + howpublished="RFC 1688 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1688", + pages="1--9", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1688.txt", + key="RFC 1688", + abstract={This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Paper", + doi="10.17487/RFC1688", + } + +@misc{rfc1689, + author="J. {Foster (Ed.)}", + title="{A Status Report on Networked Information Retrieval: Tools and Groups}", + howpublished="RFC 1689 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1689", + pages="1--226", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1689.txt", + key="RFC 1689", + abstract={The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="NIR", + doi="10.17487/RFC1689", + } + +@misc{rfc1690, + author="G. Huston", + title="{Introducing the Internet Engineering and Planning Group (IEPG)}", + howpublished="RFC 1690 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1690", + pages="1--2", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1690.txt", + key="RFC 1690", + abstract={This memo introduces the IEPG to the Internet Community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="charter", + doi="10.17487/RFC1690", + } + +@misc{rfc1691, + author="W. Turner", + title="{The Document Architecture for the Cornell Digital Library}", + howpublished="RFC 1691 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1691", + pages="1--10", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1691.txt", + key="RFC 1691", + abstract={This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1691", + } + +@misc{rfc1692, + author="P. Cameron and D. Crocker and D. Cohen and J. Postel", + title="{Transport Multiplexing Protocol (TMux)}", + howpublished="RFC 1692 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1692", + pages="1--12", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1692.txt", + key="RFC 1692", + abstract={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.}, + keywords="TMUX, Internet, Protocol, IP", + doi="10.17487/RFC1692", + } + +@misc{rfc1693, + author="T. Connolly and P. Amer and P. Conrad", + title="{An Extension to TCP : Partial Order Service}", + howpublished="RFC 1693 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1693", + pages="1--36", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6247", +url="https://www.rfc-editor.org/rfc/rfc1693.txt", + key="RFC 1693", + abstract={This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TCP-POS, Transmission, Control, Protocol", + doi="10.17487/RFC1693", + } + +@misc{rfc1694, + author="T. {Brown (Ed.)} and K. {Tesink (Ed.)}", + title="{Definitions of Managed Objects for SMDS Interfaces using SMIv2}", + howpublished="RFC 1694 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1694", + pages="1--35", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1694.txt", + key="RFC 1694", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing objects for SMDS access interfaces. [STANDARDS-TRACK]}, + keywords="SIP-MIB, Standard,MIB,Network,Management,Switched,Multimegabit,Data,Service,Informatiom,Base,SMDS", + doi="10.17487/RFC1694", + } + +@misc{rfc1695, + author="M. {Ahmed (Ed.)} and K. {Tesink (Ed.)}", + title="{Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2}", + howpublished="RFC 1695 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1695", + pages="1--73", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2515", +url="https://www.rfc-editor.org/rfc/rfc1695.txt", + key="RFC 1695", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]}, + keywords="ATM-MIB, MIB, Management,Information,Base,Asychronous,Transmission,Mode", + doi="10.17487/RFC1695", + } + +@misc{rfc1696, + author="J. Barnes and L. Brown and R. Royston and S. Waldbusser", + title="{Modem Management Information Base (MIB) using SMIv2}", + howpublished="RFC 1696 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1696", + pages="1--31", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1696.txt", + key="RFC 1696", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK]}, + keywords="MODEM-MIB", + doi="10.17487/RFC1696", + } + +@misc{rfc1697, + author="D. {Brower (Ed.)} and B. Purvy and A. Daniel and M. Sinykin and J. Smith", + title="{Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2}", + howpublished="RFC 1697 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1697", + pages="1--38", + year=1994, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1697.txt", + key="RFC 1697", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK]}, + keywords="RDBMS-MIB", + doi="10.17487/RFC1697", + } + +@misc{rfc1698, + author="P. Furniss", + title="{Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications}", + howpublished="RFC 1698 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1698", + pages="1--29", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1698.txt", + key="RFC 1698", + abstract={This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with ``basic communications requirements''. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Protocol, Headers", + doi="10.17487/RFC1698", + } + +@misc{rfc1699, + author="J. Elliott", + title="{Summary of 1600-1699}", + howpublished="RFC 1699 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1699", + pages="1--21", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1699.txt", + key="RFC 1699", + keywords="Index", + doi="10.17487/RFC1699", + } + +@misc{rfc1700, + author="J. Reynolds and J. Postel", + title="{Assigned Numbers}", + howpublished="RFC 1700 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1700", + pages="1--230", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3232", +url="https://www.rfc-editor.org/rfc/rfc1700.txt", + key="RFC 1700", + abstract={This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.}, + keywords="status, procedure, index, parameters, registered, allocated", + doi="10.17487/RFC1700", + } + +@misc{rfc1701, + author="S. Hanks and T. Li and D. Farinacci and P. Traina", + title="{Generic Routing Encapsulation (GRE)}", + howpublished="RFC 1701 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1701", + pages="1--8", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1701.txt", + key="RFC 1701", + abstract={This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="GRE, Internet, Protocol, IP", + doi="10.17487/RFC1701", + } + +@misc{rfc1702, + author="S. Hanks and T. Li and D. Farinacci and P. Traina", + title="{Generic Routing Encapsulation over IPv4 networks}", + howpublished="RFC 1702 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1702", + pages="1--4", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1702.txt", + key="RFC 1702", + abstract={This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="GRE-IPv4, Internet, Protocol, IP", + doi="10.17487/RFC1702", + } + +@misc{rfc1703, + author="M. Rose", + title="{Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures}", + howpublished="RFC 1703 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1703", + pages="1--9", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1703.txt", + key="RFC 1703", + abstract={This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RADIO-PAGE, Beepers", + doi="10.17487/RFC1703", + } + +@misc{rfc1704, + author="N. Haller and R. Atkinson", + title="{On Internet Authentication}", + howpublished="RFC 1704 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1704", + pages="1--17", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1704.txt", + key="RFC 1704", + abstract={This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Security, Energyption, Policy, Guidelines", + doi="10.17487/RFC1704", + } + +@misc{rfc1705, + author="R. Carlson and D. Ficarella", + title="{Six Virtual Inches to the Left: The Problem with IPng}", + howpublished="RFC 1705 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1705", + pages="1--27", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1705.txt", + key="RFC 1705", + abstract={This document was submitted to the IETF IPng area in response to RFC 1550. This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPng, White paper", + doi="10.17487/RFC1705", + } + +@misc{rfc1706, + author="B. Manning and R. Colella", + title="{DNS NSAP Resource Records}", + howpublished="RFC 1706 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1706", + pages="1--10", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1706.txt", + key="RFC 1706", + abstract={This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="DNS-NSAP, Domain, Name, System, ISO, OSI, Address, RR, Record, Resource", + doi="10.17487/RFC1706", + } + +@misc{rfc1707, + author="M. McGovern and R. Ullmann", + title="{CATNIP: Common Architecture for the Internet}", + howpublished="RFC 1707 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1707", + pages="1--16", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1707.txt", + key="RFC 1707", + abstract={This document was submitted to the IETF IPng area in response to RFC 1550. This paper describes a common architecture for the network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPng, White, Paper, IPv7", + doi="10.17487/RFC1707", + } + +@misc{rfc1708, + author="D. Gowin", + title="{NTP PICS PROFORMA - For the Network Time Protocol Version 3}", + howpublished="RFC 1708 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1708", + pages="1--13", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1708.txt", + key="RFC 1708", + abstract={This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1708", + } + +@misc{rfc1709, + author="J. Gargano and D. Wasley", + title="{K-12 Internetworking Guidelines}", + howpublished="RFC 1709 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1709", + pages="1--26", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1709.txt", + key="RFC 1709", + abstract={The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="school, network, education, connection", + doi="10.17487/RFC1709", + } + +@misc{rfc1710, + author="R. Hinden", + title="{Simple Internet Protocol Plus White Paper}", + howpublished="RFC 1710 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1710", + pages="1--23", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1710.txt", + key="RFC 1710", + abstract={This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="SIPP, IPng", + doi="10.17487/RFC1710", + } + +@misc{rfc1711, + author="J. Houttuin", + title="{Classifications in E-mail Routing}", + howpublished="RFC 1711 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1711", + pages="1--19", + year=1994, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1711.txt", + key="RFC 1711", + abstract={This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Email, Electronic, Mail", + doi="10.17487/RFC1711", + } + +@misc{rfc1712, + author="C. Farrell and M. Schulze and S. Pleitner and D. Baldoni", + title="{DNS Encoding of Geographical Location}", + howpublished="RFC 1712 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1712", + pages="1--7", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1712.txt", + key="RFC 1712", + abstract={This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="DNS-ENCODE, Domain, Names, System, GPOS", + doi="10.17487/RFC1712", + } + +@misc{rfc1713, + author="A. Romao", + title="{Tools for DNS debugging}", + howpublished="RFC 1713 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1713", + pages="1--13", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1713.txt", + key="RFC 1713", + abstract={Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Domain, Names, System, Host, DNSWalk, DOC, DDT, Checker", + doi="10.17487/RFC1713", + } + +@misc{rfc1714, + author="S. Williamson and M. Kosters", + title="{Referral Whois Protocol (RWhois)}", + howpublished="RFC 1714 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1714", + pages="1--46", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2167", +url="https://www.rfc-editor.org/rfc/rfc1714.txt", + key="RFC 1714", + abstract={This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Pages, Directory", + doi="10.17487/RFC1714", + } + +@misc{rfc1715, + author="C. Huitema", + title="{The H Ratio for Address Assignment Efficiency}", + howpublished="RFC 1715 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1715", + pages="1--4", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3194", +url="https://www.rfc-editor.org/rfc/rfc1715.txt", + key="RFC 1715", + abstract={This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPng, White, Paper", + doi="10.17487/RFC1715", + } + +@misc{rfc1716, + author="P. Almquist and F. Kastenholz", + title="{Towards Requirements for IP Routers}", + howpublished="RFC 1716 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1716", + pages="1--192", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1812", +url="https://www.rfc-editor.org/rfc/rfc1716.txt", + key="RFC 1716", + abstract={The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Gateway, Internet, Protocol", + doi="10.17487/RFC1716", + } + +@misc{rfc1717, + author="K. Sklower and B. Lloyd and G. McGregor and D. Carr", + title="{The PPP Multilink Protocol (MP)}", + howpublished="RFC 1717 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1717", + pages="1--21", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1990", +url="https://www.rfc-editor.org/rfc/rfc1717.txt", + key="RFC 1717", + abstract={This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]}, + keywords="Point", + doi="10.17487/RFC1717", + } + +@misc{rfc1718, + author="IETF Secretariat and G. Malkin", + title="{The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force}", + howpublished="RFC 1718 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1718", + pages="1--23", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3160", +url="https://www.rfc-editor.org/rfc/rfc1718.txt", + key="RFC 1718", + abstract={The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]}, + keywords="Internet, Engineering, Task, Force, Meeting", + doi="10.17487/RFC1718", + } + +@misc{rfc1719, + author="P. Gross", + title="{A Direction for IPng}", + howpublished="RFC 1719 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1719", + pages="1--6", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1719.txt", + key="RFC 1719", + abstract={This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPng, White, Paper, Internet, Protocol", + doi="10.17487/RFC1719", + } + +@misc{rfc1720, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1720 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1720", + pages="1--41", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1780", +url="https://www.rfc-editor.org/rfc/rfc1720.txt", + key="RFC 1720", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1720", + } + +@misc{rfc1721, + author="G. Malkin", + title="{RIP Version 2 Protocol Analysis}", + howpublished="RFC 1721 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1721", + pages="1--4", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1721.txt", + key="RFC 1721", + abstract={As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RIP-2", + doi="10.17487/RFC1721", + } + +@misc{rfc1722, + author="G. Malkin", + title="{RIP Version 2 Protocol Applicability Statement}", + howpublished="RFC 1722 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1722", + pages="1--5", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1722.txt", + key="RFC 1722", + abstract={As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet. This report is a prerequisite to advancing RIP-2 on the standards track. [STANDARDS-TRACK]}, + keywords="RIP2-APP, RIP-2", + doi="10.17487/RFC1722", + } + +@misc{rfc1723, + author="G. Malkin", + title="{RIP Version 2 - Carrying Additional Information}", + howpublished="RFC 1723 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1723", + pages="1--9", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2453", +url="https://www.rfc-editor.org/rfc/rfc1723.txt", + key="RFC 1723", + abstract={This document specifies an extension of the Routing Information Protocol (RIP), o expand the amount of useful information carried in RIP messages and to add a measure of security. This memo obsoletes RFC 1388, which specifies an update to the ``Routing Information Protocol'' STD 34, RFC 1058. [STANDARDS-TRACK]}, + keywords="RIP-2", + doi="10.17487/RFC1723", + } + +@misc{rfc1724, + author="G. Malkin and F. Baker", + title="{RIP Version 2 MIB Extension}", + howpublished="RFC 1724 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1724", + pages="1--18", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1724.txt", + key="RFC 1724", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing RIP Version 2. [STANDARDS-TRACK]}, + keywords="RIP2-MIB, RIP-2, Management, Information, Base", + doi="10.17487/RFC1724", + } + +@misc{rfc1725, + author="J. Myers and M. Rose", + title="{Post Office Protocol - Version 3}", + howpublished="RFC 1725 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1725", + pages="1--18", + year=1994, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1939", +url="https://www.rfc-editor.org/rfc/rfc1725.txt", + key="RFC 1725", + abstract={This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]}, + keywords="POP, Email, Electronic, Mail", + doi="10.17487/RFC1725", + } + +@misc{rfc1726, + author="C. Partridge and F. Kastenholz", + title="{Technical Criteria for Choosing IP The Next Generation (IPng)}", + howpublished="RFC 1726 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1726", + pages="1--31", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1726.txt", + key="RFC 1726", + abstract={This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPng, White, Paper, Internet, Protocol", + doi="10.17487/RFC1726", + } + +@misc{rfc1727, + author="C. Weider and P. Deutsch", + title="{A Vision of an Integrated Internet Information Service}", + howpublished="RFC 1727 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1727", + pages="1--11", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1727.txt", + key="RFC 1727", + abstract={This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Universal, Resource, Names", + doi="10.17487/RFC1727", + } + +@misc{rfc1728, + author="C. Weider", + title="{Resource Transponders}", + howpublished="RFC 1728 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1728", + pages="1--6", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1728.txt", + key="RFC 1728", + abstract={This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Universal, Resource, Names, Location, System", + doi="10.17487/RFC1728", + } + +@misc{rfc1729, + author="C. Lynch", + title="{Using the Z39.50 Information Retrieval Protocol}", + howpublished="RFC 1729 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1729", + pages="1--8", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1729.txt", + key="RFC 1729", + abstract={This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Basic, Endcoding, Rules, ASN1", + doi="10.17487/RFC1729", + } + +@misc{rfc1730, + author="M. Crispin", + title="{Internet Message Access Protocol - Version 4}", + howpublished="RFC 1730 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1730", + pages="1--77", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2060, 2061", +url="https://www.rfc-editor.org/rfc/rfc1730.txt", + key="RFC 1730", + abstract={The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called ``mailboxes'', in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server. [STANDARDS-TRACK]}, + keywords="IMAP, IMAP4, EMail", + doi="10.17487/RFC1730", + } + +@misc{rfc1731, + author="J. Myers", + title="{IMAP4 Authentication Mechanisms}", + howpublished="RFC 1731 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1731", + pages="1--6", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1731.txt", + key="RFC 1731", + abstract={The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]}, + keywords="IMAP4-AUTH, Internet, Message, Access, Protocol, Email", + doi="10.17487/RFC1731", + } + +@misc{rfc1732, + author="M. Crispin", + title="{IMAP4 Compatibility with IMAP2 and IMAP2bis}", + howpublished="RFC 1732 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1732", + pages="1--5", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1732.txt", + key="RFC 1732", + abstract={This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Message, Access, Protocol, Email", + doi="10.17487/RFC1732", + } + +@misc{rfc1733, + author="M. Crispin", + title="{Distributed Electronic Mail Models in IMAP4}", + howpublished="RFC 1733 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1733", + pages="1--3", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1733.txt", + key="RFC 1733", + abstract={There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Message, Access, Protocol, Email", + doi="10.17487/RFC1733", + } + +@misc{rfc1734, + author="J. Myers", + title="{POP3 AUTHentication command}", + howpublished="RFC 1734 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1734", + pages="1--5", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5034", +url="https://www.rfc-editor.org/rfc/rfc1734.txt", + key="RFC 1734", + abstract={This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]}, + keywords="POP3-AUTH, Post, Office, Protocol, Email", + doi="10.17487/RFC1734", + } + +@misc{rfc1735, + author="J. Heinanen and R. Govindan", + title="{NBMA Address Resolution Protocol (NARP)}", + howpublished="RFC 1735 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1735", + pages="1--11", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1735.txt", + key="RFC 1735", + abstract={This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="NARP, Non-Broadcast, Multi, Access, Address, Resolution, Protocol", + doi="10.17487/RFC1735", + } + +@misc{rfc1736, + author="J. Kunze", + title="{Functional Recommendations for Internet Resource Locators}", + howpublished="RFC 1736 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1736", + pages="1--10", + year=1995, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1736.txt", + key="RFC 1736", + abstract={This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Uniform, Resource, URL", + doi="10.17487/RFC1736", + } + +@misc{rfc1737, + author="K. Sollins and L. Masinter", + title="{Functional Requirements for Uniform Resource Names}", + howpublished="RFC 1737 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1737", + pages="1--7", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1737.txt", + key="RFC 1737", + abstract={This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1737", + } + +@misc{rfc1738, + author="T. Berners-Lee and L. Masinter and M. McCahill", + title="{Uniform Resource Locators (URL)}", + howpublished="RFC 1738 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1738", + pages="1--25", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4248, 4266, updated by RFCs 1808, 2368, 2396, 3986, 6196, 6270, 8089", +url="https://www.rfc-editor.org/rfc/rfc1738.txt", + key="RFC 1738", + abstract={This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]}, + keywords="URL", + doi="10.17487/RFC1738", + } + +@misc{rfc1739, + author="G. Kessler and S. Shepard", + title="{A Primer On Internet and TCP/IP Tools}", + howpublished="RFC 1739 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1739", + pages="1--46", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2151", +url="https://www.rfc-editor.org/rfc/rfc1739.txt", + key="RFC 1739", + abstract={This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="NSlookup, PING, FINGER, TRACEROUTE, FTP, TELNET, WHOIS, NICNAME, KNOWBOT, NETFIND, ARCHIE, Gopher, Email, Mailing, Lists, USENET", + doi="10.17487/RFC1739", + } + +@misc{rfc1740, + author="P. Faltstrom and D. Crocker and E. Fair", + title="{MIME Encapsulation of Macintosh Files - MacMIME}", + howpublished="RFC 1740 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1740", + pages="1--16", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1740.txt", + key="RFC 1740", + abstract={This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]}, + keywords="MacMIME, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1740", + } + +@misc{rfc1741, + author="P. Faltstrom and D. Crocker and E. Fair", + title="{MIME Content Type for BinHex Encoded Files}", + howpublished="RFC 1741 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1741", + pages="1--6", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1741.txt", + key="RFC 1741", + abstract={This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="BINHEX, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1741", + } + +@misc{rfc1742, + author="S. Waldbusser and K. Frisa", + title="{AppleTalk Management Information Base II}", + howpublished="RFC 1742 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1742", + pages="1--84", + year=1995, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1742.txt", + key="RFC 1742", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. [STANDARDS-TRACK]}, + keywords="AT-MIB", + doi="10.17487/RFC1742", + } + +@misc{rfc1743, + author="K. McCloghrie and E. Decker", + title="{IEEE 802.5 MIB using SMIv2}", + howpublished="RFC 1743 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1743", + pages="1--25", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1748", +url="https://www.rfc-editor.org/rfc/rfc1743.txt", + key="RFC 1743", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]}, + keywords="Management, Information, Base, SNMP,", + doi="10.17487/RFC1743", + } + +@misc{rfc1744, + author="G. Huston", + title="{Observations on the Management of the Internet Address Space}", + howpublished="RFC 1744 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1744", + pages="1--12", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1744.txt", + key="RFC 1744", + abstract={This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, Internet, Protocol", + doi="10.17487/RFC1744", + } + +@misc{rfc1745, + author="K. Varadhan and S. Hares and Y. Rekhter", + title="{BGP4/IDRP for IP---OSPF Interaction}", + howpublished="RFC 1745 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1745", + pages="1--19", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1745.txt", + key="RFC 1745", + abstract={This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]}, + keywords="BGP4/IDRP, Internet, Inter-Domain, Routing, Protocol, Border, Gateway, Open, Shortest, Path, First", + doi="10.17487/RFC1745", + } + +@misc{rfc1746, + author="B. Manning and D. Perkins", + title="{Ways to Define User Expectations}", + howpublished="RFC 1746 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1746", + pages="1--18", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1746.txt", + key="RFC 1746", + abstract={This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1746", + } + +@misc{rfc1747, + author="J. Hilgeman and S. Nix and A. Bartky and W. {Clark (Ed.)}", + title="{Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2}", + howpublished="RFC 1747 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1747", + pages="1--67", + year=1995, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1747.txt", + key="RFC 1747", + abstract={This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. [STANDARDS-TRACK]}, + keywords="SDLCSMIv2", + doi="10.17487/RFC1747", + } + +@misc{rfc1748, + author="K. McCloghrie and E. Decker", + title="{IEEE 802.5 MIB using SMIv2}", + howpublished="RFC 1748 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1748", + pages="1--25", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 1749", +url="https://www.rfc-editor.org/rfc/rfc1748.txt", + key="RFC 1748", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]}, + keywords="802.5-MIB, Management, Information, Base, SNMP", + doi="10.17487/RFC1748", + } + +@misc{rfc1749, + author="K. McCloghrie and F. Baker and E. Decker", + title="{IEEE 802.5 Station Source Routing MIB using SMIv2}", + howpublished="RFC 1749 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1749", + pages="1--10", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1749.txt", + key="RFC 1749", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]}, + keywords="802.5-SSR, Management, Information, Base, SNMP", + doi="10.17487/RFC1749", + } + +@misc{rfc1750, + author="D. {Eastlake 3rd} and S. Crocker and J. Schiller", + title="{Randomness Recommendations for Security}", + howpublished="RFC 1750 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1750", + pages="1--30", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4086", +url="https://www.rfc-editor.org/rfc/rfc1750.txt", + key="RFC 1750", + abstract={Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Random, Numbers, Seed", + doi="10.17487/RFC1750", + } + +@misc{rfc1751, + author="D. McDonald", + title="{A Convention for Human-Readable 128-bit Keys}", + howpublished="RFC 1751 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1751", + pages="1--15", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1751.txt", + key="RFC 1751", + abstract={This memo proposes a convention for use with Internet applications \& 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.}, + keywords="Security, Password", + doi="10.17487/RFC1751", + } + +@misc{rfc1752, + author="S. Bradner and A. Mankin", + title="{The Recommendation for the IP Next Generation Protocol}", + howpublished="RFC 1752 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1752", + pages="1--52", + year=1995, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1752.txt", + key="RFC 1752", + abstract={This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK]}, + keywords="IPNG, IPng, Internet", + doi="10.17487/RFC1752", + } + +@misc{rfc1753, + author="N. Chiappa", + title="{IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture}", + howpublished="RFC 1753 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1753", + pages="1--18", + year=1994, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1753.txt", + key="RFC 1753", + abstract={This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPng, White, Paper, Internet, Protocol", + doi="10.17487/RFC1753", + } + +@misc{rfc1754, + author="M. Laubach", + title="{IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1}", + howpublished="RFC 1754 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1754", + pages="1--7", + year=1995, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1754.txt", + key="RFC 1754", + abstract={This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Asynchromous, Transfer, Mode", + doi="10.17487/RFC1754", + } + +@misc{rfc1755, + author="M. Perez and F. Liaw and A. Mankin and E. Hoffman and D. Grossman and A. Malis", + title="{ATM Signaling Support for IP over ATM}", + howpublished="RFC 1755 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1755", + pages="1--32", + year=1995, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1755.txt", + key="RFC 1755", + abstract={This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK]}, + keywords="ATM, Asynchronous, Transfer, Mode", + doi="10.17487/RFC1755", + } + +@misc{rfc1756, + author="T. Rinne", + title="{Remote Write Protocol - Version 1.0}", + howpublished="RFC 1756 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1756", + pages="1--11", + year=1995, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1756.txt", + key="RFC 1756", + abstract={This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RWP, Application", + doi="10.17487/RFC1756", + } + +@misc{rfc1757, + author="S. Waldbusser", + title="{Remote Network Monitoring Management Information Base}", + howpublished="RFC 1757 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1757", + pages="1--91", + year=1995, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2819", +url="https://www.rfc-editor.org/rfc/rfc1757.txt", + key="RFC 1757", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]}, + keywords="RMON-MIB, MIB, RMON", + doi="10.17487/RFC1757", + } + +@misc{rfc1758, + author="The North American Directory Forum", + title="{NADF Standing Documents: A Brief Overview}", + howpublished="RFC 1758 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1758", + pages="1--4", + year=1995, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1758.txt", + key="RFC 1758", + abstract={The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="X.500, North, American, Directory, Forum, Public, CCITT, Providers", + doi="10.17487/RFC1758", + } + +@misc{rfc1759, + author="R. Smith and F. Wright and T. Hastings and S. Zilles and J. Gyllenskog", + title="{Printer MIB}", + howpublished="RFC 1759 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1759", + pages="1--113", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3805", +url="https://www.rfc-editor.org/rfc/rfc1759.txt", + key="RFC 1759", + abstract={A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]}, + keywords="Print-MIB, Management, Information, Base", + doi="10.17487/RFC1759", + } + +@misc{rfc1760, + author="N. Haller", + title="{The S/KEY One-Time Password System}", + howpublished="RFC 1760 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1760", + pages="1--12", + year=1995, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1760.txt", + key="RFC 1760", + abstract={This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Security", + doi="10.17487/RFC1760", + } + +@misc{rfc1761, + author="B. Callaghan and R. Gilligan", + title="{Snoop Version 2 Packet Capture File Format}", + howpublished="RFC 1761 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1761", + pages="1--6", + year=1995, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1761.txt", + key="RFC 1761", + abstract={This paper describes the file format used by ``snoop'', a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="SNOOP, Measurement, debugging, collecting, data", + doi="10.17487/RFC1761", + } + +@misc{rfc1762, + author="S. Senum", + title="{The PPP DECnet Phase IV Control Protocol (DNCP)}", + howpublished="RFC 1762 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1762", + pages="1--7", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1762.txt", + key="RFC 1762", + abstract={This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). [STANDARDS-TRACK]}, + keywords="PPP-DNCP, Point, Digital, Equipment, Corporation", + doi="10.17487/RFC1762", + } + +@misc{rfc1763, + author="S. Senum", + title="{The PPP Banyan Vines Control Protocol (BVCP)}", + howpublished="RFC 1763 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1763", + pages="1--10", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1763.txt", + key="RFC 1763", + abstract={This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK]}, + keywords="BVCP, Point", + doi="10.17487/RFC1763", + } + +@misc{rfc1764, + author="S. Senum", + title="{The PPP XNS IDP Control Protocol (XNSCP)}", + howpublished="RFC 1764 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1764", + pages="1--5", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1764.txt", + key="RFC 1764", + abstract={This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK]}, + keywords="XNSCP, Point, Xerox, Network, Internetwork, Datagram, Service", + doi="10.17487/RFC1764", + } + +@misc{rfc1765, + author="J. Moy", + title="{OSPF Database Overflow}", + howpublished="RFC 1765 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1765", + pages="1--9", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1765.txt", + key="RFC 1765", + abstract={This memo details a way of gracefully handling unanticipated database overflows. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="OSPF-OVFL", + doi="10.17487/RFC1765", + } + +@misc{rfc1766, + author="H. Alvestrand", + title="{Tags for the Identification of Languages}", + howpublished="RFC 1766 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1766", + pages="1--9", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 3066, 3282", +url="https://www.rfc-editor.org/rfc/rfc1766.txt", + key="RFC 1766", + abstract={This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK]}, + keywords="Lang-Tag", + doi="10.17487/RFC1766", + } + +@misc{rfc1767, + author="D. Crocker", + title="{MIME Encapsulation of EDI Objects}", + howpublished="RFC 1767 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1767", + pages="1--7", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1767.txt", + key="RFC 1767", + abstract={Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]}, + keywords="MIME-EDI, Electronic, Data, Interchange, Multipurpose, Internet, Mail, Extensions, delivery, mechanism, encapsulation", + doi="10.17487/RFC1767", + } + +@misc{rfc1768, + author="D. Marlow", + title="{Host Group Extensions for CLNP Multicasting}", + howpublished="RFC 1768 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1768", + pages="1--45", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1768.txt", + key="RFC 1768", + abstract={This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="CLNP-MULT, ISO, OSI", + doi="10.17487/RFC1768", + } + +@misc{rfc1769, + author="D. Mills", + title="{Simple Network Time Protocol (SNTP)}", + howpublished="RFC 1769 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1769", + pages="1--14", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2030, 4330", +url="https://www.rfc-editor.org/rfc/rfc1769.txt", + key="RFC 1769", + abstract={This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Clocks, Synchronization, NTP", + doi="10.17487/RFC1769", + } + +@misc{rfc1770, + author="C. Graff", + title="{IPv4 Option for Sender Directed Multi-Destination Delivery}", + howpublished="RFC 1770 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1770", + pages="1--6", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6814", +url="https://www.rfc-editor.org/rfc/rfc1770.txt", + key="RFC 1770", + abstract={This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="SDMD", + doi="10.17487/RFC1770", + } + +@misc{rfc1771, + author="Y. Rekhter and T. Li", + title="{A Border Gateway Protocol 4 (BGP-4)}", + howpublished="RFC 1771 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1771", + pages="1--57", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4271", +url="https://www.rfc-editor.org/rfc/rfc1771.txt", + key="RFC 1771", + abstract={This document, together with its companion document, ``Application of the Border Gateway Protocol in the Internet'', define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]}, + keywords="BGP-4, routing", + doi="10.17487/RFC1771", + } + +@misc{rfc1772, + author="Y. Rekhter and P. Gross", + title="{Application of the Border Gateway Protocol in the Internet}", + howpublished="RFC 1772 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1772", + pages="1--19", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1772.txt", + key="RFC 1772", + abstract={This document, together with its companion document, ``A Border Gateway Protocol 4 (BGP-4)'', define an inter-autonomous system routing protocol for the Internet. This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]}, + keywords="BGP-4-APP, BGP-4, Routing", + doi="10.17487/RFC1772", + } + +@misc{rfc1773, + author="P. Traina", + title="{Experience with the BGP-4 protocol}", + howpublished="RFC 1773 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1773", + pages="1--9", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1773.txt", + key="RFC 1773", + abstract={The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="BGP-4, Border, Gateway, Protocol, Routing", + doi="10.17487/RFC1773", + } + +@misc{rfc1774, + author="P. {Traina (Ed.)}", + title="{BGP-4 Protocol Analysis}", + howpublished="RFC 1774 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1774", + pages="1--10", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1774.txt", + key="RFC 1774", + abstract={The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Border, Gateway, Routing", + doi="10.17487/RFC1774", + } + +@misc{rfc1775, + author="D. Crocker", + title="{To Be ``On'' the Internet}", + howpublished="RFC 1775 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1775", + pages="1--4", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1775.txt", + key="RFC 1775", + abstract={The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is ``on'' the Internet. This document suggests four terms, for distinguishing the major classes of access. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="access, full, Client, Mediated, Messaging", + doi="10.17487/RFC1775", + } + +@misc{rfc1776, + author="S. Crocker", + title="{The Address is the Message}", + howpublished="RFC 1776 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1776", + pages="1--2", + year=1995, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1776.txt", + key="RFC 1776", + abstract={Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPng", + doi="10.17487/RFC1776", + } + +@misc{rfc1777, + author="W. Yeong and T. Howes and S. Kille", + title="{Lightweight Directory Access Protocol}", + howpublished="RFC 1777 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1777", + pages="1--22", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3494", +url="https://www.rfc-editor.org/rfc/rfc1777.txt", + key="RFC 1777", + abstract={The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP).This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself. [STANDARDS-TRACK]}, + keywords="X.500, DAP, interactive, access", + doi="10.17487/RFC1777", + } + +@misc{rfc1778, + author="T. Howes and S. Kille and W. Yeong and C. Robbins", + title="{The String Representation of Standard Attribute Syntaxes}", + howpublished="RFC 1778 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1778", + pages="1--12", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3494, updated by RFC 2559", +url="https://www.rfc-editor.org/rfc/rfc1778.txt", + key="RFC 1778", + abstract={The Lightweight Directory Access Protocol (LDAP) requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes. [STANDARDS-TRACK]}, + keywords="X.500, LDAP, lightweight directory protocol", + doi="10.17487/RFC1778", + } + +@misc{rfc1779, + author="S. Kille", + title="{A String Representation of Distinguished Names}", + howpublished="RFC 1779 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1779", + pages="1--8", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2253, 3494", +url="https://www.rfc-editor.org/rfc/rfc1779.txt", + key="RFC 1779", + abstract={The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. [STANDARDS-TRACK]}, + keywords="STR-REP, X.500, directory names, representing names", + doi="10.17487/RFC1779", + } + +@misc{rfc1780, + author="J. {Postel (Ed.)}", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1780 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1780", + pages="1--39", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1800", +url="https://www.rfc-editor.org/rfc/rfc1780.txt", + key="RFC 1780", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1780", + } + +@misc{rfc1781, + author="S. Kille", + title="{Using the OSI Directory to Achieve User Friendly Naming}", + howpublished="RFC 1781 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1781", + pages="1--26", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3494", +url="https://www.rfc-editor.org/rfc/rfc1781.txt", + key="RFC 1781", + abstract={This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. [STANDARDS-TRACK]}, + keywords="OSI-Dir, X.500, directory names, representing names", + doi="10.17487/RFC1781", + } + +@misc{rfc1782, + author="G. Malkin and A. Harkin", + title="{TFTP Option Extension}", + howpublished="RFC 1782 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1782", + pages="1--6", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2347", +url="https://www.rfc-editor.org/rfc/rfc1782.txt", + key="RFC 1782", + abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.}, + keywords="trivial, file, transfer, booting", + doi="10.17487/RFC1782", + } + +@misc{rfc1783, + author="G. Malkin and A. Harkin", + title="{TFTP Blocksize Option}", + howpublished="RFC 1783 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1783", + pages="1--5", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2348", +url="https://www.rfc-editor.org/rfc/rfc1783.txt", + key="RFC 1783", + abstract={This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]}, + keywords="trivial, file, transfer, booting", + doi="10.17487/RFC1783", + } + +@misc{rfc1784, + author="G. Malkin and A. Harkin", + title="{TFTP Timeout Interval and Transfer Size Options}", + howpublished="RFC 1784 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1784", + pages="1--4", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2349", +url="https://www.rfc-editor.org/rfc/rfc1784.txt", + key="RFC 1784", + abstract={This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. [STANDARDS-TRACK]}, + keywords="trivial, file, transfer, booting", + doi="10.17487/RFC1784", + } + +@misc{rfc1785, + author="G. Malkin and A. Harkin", + title="{TFTP Option Negotiation Analysis}", + howpublished="RFC 1785 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1785", + pages="1--2", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1785.txt", + key="RFC 1785", + abstract={This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="trivial, file, transfer, booting", + doi="10.17487/RFC1785", + } + +@misc{rfc1786, + author="T. Bates and E. Gerich and L. Joncheray and J-M. Jouanigot and D. Karrenberg and M. Terpstra and J. Yu", + title="{Representation of IP Routing Policies in a Routing Registry (ripe-81++)}", + howpublished="RFC 1786 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1786", + pages="1--83", + year=1995, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1786.txt", + key="RFC 1786", + abstract={This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc. and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1786", + } + +@misc{rfc1787, + author="Y. Rekhter", + title="{Routing in a Multi-provider Internet}", + howpublished="RFC 1787 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1787", + pages="1--8", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1787.txt", + key="RFC 1787", + abstract={This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Protocol, Architechure Board, IAB", + doi="10.17487/RFC1787", + } + +@misc{rfc1788, + author="W. Simpson", + title="{ICMP Domain Name Messages}", + howpublished="RFC 1788 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1788", + pages="1--7", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6918", +url="https://www.rfc-editor.org/rfc/rfc1788.txt", + key="RFC 1788", + abstract={This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.}, + keywords="ICMP-DM, Internet, Control, Message, Protocol, DNS, Service", + doi="10.17487/RFC1788", + } + +@misc{rfc1789, + author="C. Yang", + title="{INETPhone: Telephone Services and Servers on Internet}", + howpublished="RFC 1789 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1789", + pages="1--6", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1789.txt", + key="RFC 1789", + abstract={This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1789", + } + +@misc{rfc1790, + author="V. Cerf", + title="{An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols}", + howpublished="RFC 1790 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1790", + pages="1--4", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1790.txt", + key="RFC 1790", + abstract={This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="ISOC", + doi="10.17487/RFC1790", + } + +@misc{rfc1791, + author="T. Sung", + title="{TCP And UDP Over IPX Networks With Fixed Path MTU}", + howpublished="RFC 1791 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1791", + pages="1--12", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1791.txt", + key="RFC 1791", + abstract={TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.}, + keywords="Transmission, Control, Protocol, User, Datagram, Maxium, Unit", + doi="10.17487/RFC1791", + } + +@misc{rfc1792, + author="T. Sung", + title="{TCP/IPX Connection Mib Specification}", + howpublished="RFC 1792 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1792", + pages="1--9", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1792.txt", + key="RFC 1792", + abstract={New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.}, + keywords="TCP/IPXMIB, Transmission, Control, Protocol, Management, Information, Base", + doi="10.17487/RFC1792", + } + +@misc{rfc1793, + author="J. Moy", + title="{Extending OSPF to Support Demand Circuits}", + howpublished="RFC 1793 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1793", + pages="1--32", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3883", +url="https://www.rfc-editor.org/rfc/rfc1793.txt", + key="RFC 1793", + abstract={This memo defines enhancements to the OSPF protocol that allow efficient operation over ``demand circuits''. [STANDARDS-TRACK]}, + keywords="OSPF-DC, Open, Shortest, Path, First", + doi="10.17487/RFC1793", + } + +@misc{rfc1794, + author="T. Brisco", + title="{DNS Support for Load Balancing}", + howpublished="RFC 1794 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1794", + pages="1--7", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1794.txt", + key="RFC 1794", + abstract={This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Domain, Name, System", + doi="10.17487/RFC1794", + } + +@misc{rfc1795, + author="L. Wells and A. {Bartky (Ed.)}", + title="{Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1}", + howpublished="RFC 1795 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1795", + pages="1--91", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1795.txt", + key="RFC 1795", + abstract={This RFC describes use of Data Link Switching over TCP/IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IBM, SNA, DLS, SSP, NetBIos, APPN", + doi="10.17487/RFC1795", + } + +@misc{rfc1796, + author="C. Huitema and J. Postel and S. Crocker", + title="{Not All RFCs are Standards}", + howpublished="RFC 1796 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1796", + pages="1--4", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1796.txt", + key="RFC 1796", + abstract={This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1796", + } + +@misc{rfc1797, + author="Internet Assigned Numbers Authority (IANA)", + title="{Class A Subnet Experiment}", + howpublished="RFC 1797 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1797", + pages="1--4", + year=1995, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1797.txt", + key="RFC 1797", + abstract={There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.}, + keywords="Network, Address, 39, Number", + doi="10.17487/RFC1797", + } + +@misc{rfc1798, + author="A. Young", + title="{Connection-less Lightweight X.500 Directory Access Protocol}", + howpublished="RFC 1798 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1798", + pages="1--9", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3352", +url="https://www.rfc-editor.org/rfc/rfc1798.txt", + key="RFC 1798", + abstract={The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]}, + keywords="CLDAP, CLDAP, Presentation, Address, Application, Entity, Title", + doi="10.17487/RFC1798", + } + +@misc{rfc1799, + author="M. Kennedy", + title="{Request for Comments Summary RFC Numbers 1700-1799}", + howpublished="RFC 1799 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1799", + pages="1--21", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1799.txt", + key="RFC 1799", + keywords="Index", + doi="10.17487/RFC1799", + } + +@misc{rfc1800, + author="J. {Postel (Ed.)}", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1800 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1800", + pages="1--36", + year=1995, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1880", +url="https://www.rfc-editor.org/rfc/rfc1800.txt", + key="RFC 1800", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1800", + } + +@misc{rfc1801, + author="S. Kille", + title="{MHS use of the X.500 Directory to support MHS Routing}", + howpublished="RFC 1801 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1801", + pages="1--73", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1801.txt", + key="RFC 1801", + abstract={The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is ``nearer'' to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community.}, + keywords="Routing, Mail, EMail, Message, Handling, System, X.400", + doi="10.17487/RFC1801", + } + +@misc{rfc1802, + author="H. Alvestrand and K. Jordan and S. Langlois and J. Romaguera", + title="{Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing}", + howpublished="RFC 1802 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1802", + pages="1--11", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1802.txt", + key="RFC 1802", + abstract={This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Mail, EMail, Message, Handling, System, MHS", + doi="10.17487/RFC1802", + } + +@misc{rfc1803, + author="R. Wright and A. Getchell and T. Howes and S. Sataluri and P. Yee and W. Yeong", + title="{Recommendations for an X.500 Production Directory Service}", + howpublished="RFC 1803 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1803", + pages="1--8", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1803.txt", + key="RFC 1803", + abstract={This document contains a set of basic recommendations for a country- level X.500 DSA. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="White, Pages, DSA, Directory, User, Agent", + doi="10.17487/RFC1803", + } + +@misc{rfc1804, + author="G. Mansfield and P. Rajeev and S. Raghavan and T. Howes", + title="{Schema Publishing in X.500 Directory}", + howpublished="RFC 1804 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1804", + pages="1--10", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1804.txt", + key="RFC 1804", + abstract={In this document we propose a solution using the existing mechanisms of the directory [1] itself. We present a naming scheme for naming schema objects and a meta-schema for storing schema objects in the directory. This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC1804", + } + +@misc{rfc1805, + author="A. Rubin", + title="{Location-Independent Data/Software Integrity Protocol}", + howpublished="RFC 1805 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1805", + pages="1--6", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1805.txt", + key="RFC 1805", + abstract={This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Betsi, Security, Cryptography", + doi="10.17487/RFC1805", + } + +@misc{rfc1806, + author="R. Troost and S. Dorner", + title="{Communicating Presentation Information in Internet Messages: The Content-Disposition Header}", + howpublished="RFC 1806 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1806", + pages="1--8", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2183", +url="https://www.rfc-editor.org/rfc/rfc1806.txt", + key="RFC 1806", + abstract={This memo provides a mechanism whereby messages conforming to the [RFC 1521] (``MIME'') specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MIME, EMail, Mail", + doi="10.17487/RFC1806", + } + +@misc{rfc1807, + author="R. Lasher and D. Cohen", + title="{A Format for Bibliographic Records}", + howpublished="RFC 1807 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1807", + pages="1--15", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1807.txt", + key="RFC 1807", + abstract={This RFC defines a format for bibliographic records describing technical reports. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="library, technical reports, email services", + doi="10.17487/RFC1807", + } + +@misc{rfc1808, + author="R. Fielding", + title="{Relative Uniform Resource Locators}", + howpublished="RFC 1808 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1808", + pages="1--16", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3986, updated by RFCs 2368, 2396", +url="https://www.rfc-editor.org/rfc/rfc1808.txt", + key="RFC 1808", + abstract={In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative Uniform Resource Locators. [STANDARDS-TRACK]}, + keywords="URL, URL, syntax, semantics", + doi="10.17487/RFC1808", + } + +@misc{rfc1809, + author="C. Partridge", + title="{Using the Flow Label Field in IPv6}", + howpublished="RFC 1809 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1809", + pages="1--6", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1809.txt", + key="RFC 1809", + abstract={The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1809", + } + +@misc{rfc1810, + author="J. Touch", + title="{Report on MD5 Performance}", + howpublished="RFC 1810 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1810", + pages="1--7", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1810.txt", + key="RFC 1810", + abstract={This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPv6, Message, Digest, Algorithm, Authentication", + doi="10.17487/RFC1810", + } + +@misc{rfc1811, + author="Federal Networking Council", + title="{U.S. Government Internet Domain Names}", + howpublished="RFC 1811 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1811", + pages="1--3", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1816", +url="https://www.rfc-editor.org/rfc/rfc1811.txt", + key="RFC 1811", + abstract={This document describes the registration policies for the top-level domain ``.GOV''. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="GOV, FNC, IANA", + doi="10.17487/RFC1811", + } + +@misc{rfc1812, + author="F. {Baker (Ed.)}", + title="{Requirements for IP Version 4 Routers}", + howpublished="RFC 1812 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1812", + pages="1--175", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2644, 6633", +url="https://www.rfc-editor.org/rfc/rfc1812.txt", + key="RFC 1812", + abstract={This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]}, + keywords="routing, IPv4", + doi="10.17487/RFC1812", + } + +@misc{rfc1813, + author="B. Callaghan and B. Pawlowski and P. Staubach", + title="{NFS Version 3 Protocol Specification}", + howpublished="RFC 1813 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1813", + pages="1--126", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1813.txt", + key="RFC 1813", + abstract={This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="NFSV3", + doi="10.17487/RFC1813", + } + +@misc{rfc1814, + author="E. Gerich", + title="{Unique Addresses are Good}", + howpublished="RFC 1814 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1814", + pages="1--3", + year=1995, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1814.txt", + key="RFC 1814", + abstract={The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Registries, Protocol, Private, Network, Numbers", + doi="10.17487/RFC1814", + } + +@misc{rfc1815, + author="M. Ohta", + title="{Character Sets ISO-10646 and ISO-10646-J-1}", + howpublished="RFC 1815 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1815", + pages="1--6", + year=1995, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1815.txt", + key="RFC 1815", + abstract={For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary. This memo provides information on such profiling, along with charset names to each profiled instance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Japanese, Latin", + doi="10.17487/RFC1815", + } + +@misc{rfc1816, + author="Federal Networking Council", + title="{U.S. Government Internet Domain Names}", + howpublished="RFC 1816 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1816", + pages="1--8", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2146", +url="https://www.rfc-editor.org/rfc/rfc1816.txt", + key="RFC 1816", + abstract={This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain ``.GOV''. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="GOV, FNC, IANA", + doi="10.17487/RFC1816", + } + +@misc{rfc1817, + author="Y. Rekhter", + title="{CIDR and Classful Routing}", + howpublished="RFC 1817 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1817", + pages="1--2", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1817.txt", + key="RFC 1817", + abstract={This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Classless, Inter, Domain, Routing", + doi="10.17487/RFC1817", + } + +@misc{rfc1818, + author="J. Postel and T. Li and Y. Rekhter", + title="{Best Current Practices}", + howpublished="RFC 1818 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1818", + pages="1--3", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1818.txt", + key="RFC 1818", + abstract={This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).}, + keywords="BCP", + doi="10.17487/RFC1818", + } + +@misc{rfc1819, + author="L. {Delgrossi (Ed.)} and L. {Berger (Ed.)}", + title="{Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+}", + howpublished="RFC 1819 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1819", + pages="1--109", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1819.txt", + key="RFC 1819", + abstract={This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). This memo defines an Experimental Protocol for the Internet community.}, + keywords="ST2", + doi="10.17487/RFC1819", + } + +@misc{rfc1820, + author="E. Huizer", + title="{Multimedia E-mail (MIME) User Agent Checklist}", + howpublished="RFC 1820 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1820", + pages="1--8", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1844", +url="https://www.rfc-editor.org/rfc/rfc1820.txt", + key="RFC 1820", + abstract={This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Multipurpose, Internet, Mail, Extensions, Media, Types", + doi="10.17487/RFC1820", + } + +@misc{rfc1821, + author="M. Borden and E. Crawley and B. Davie and S. Batsell", + title="{Integration of Real-time Services in an IP-ATM Network Architecture}", + howpublished="RFC 1821 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1821", + pages="1--24", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1821.txt", + key="RFC 1821", + abstract={The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Asynchronous, Transfer, Mode", + doi="10.17487/RFC1821", + } + +@misc{rfc1822, + author="J. Lowe", + title="{A Grant of Rights to Use a Specific IBM patent with Photuris}", + howpublished="RFC 1822 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1822", + pages="1--2", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1822.txt", + key="RFC 1822", + abstract={This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Key, Management, Protocol, IKMP, IETF", + doi="10.17487/RFC1822", + } + +@misc{rfc1823, + author="T. Howes and M. Smith", + title="{The LDAP Application Program Interface}", + howpublished="RFC 1823 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1823", + pages="1--22", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1823.txt", + key="RFC 1823", + abstract={This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="lightweight, directory, access, protocol, API, X.500", + doi="10.17487/RFC1823", + } + +@misc{rfc1824, + author="H. Danisch", + title="{The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)}", + howpublished="RFC 1824 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1824", + pages="1--21", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1824.txt", + key="RFC 1824", + abstract={This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="TESS, public, keys", + doi="10.17487/RFC1824", + } + +@misc{rfc1825, + author="R. Atkinson", + title="{Security Architecture for the Internet Protocol}", + howpublished="RFC 1825 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1825", + pages="1--22", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2401", +url="https://www.rfc-editor.org/rfc/rfc1825.txt", + key="RFC 1825", + abstract={This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]}, + keywords="IPv4, IPv6, IP-layer, ipsec", + doi="10.17487/RFC1825", + } + +@misc{rfc1826, + author="R. Atkinson", + title="{IP Authentication Header}", + howpublished="RFC 1826 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1826", + pages="1--13", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2402", +url="https://www.rfc-editor.org/rfc/rfc1826.txt", + key="RFC 1826", + abstract={This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]}, + keywords="ipsec, IPV6-AH, Internet, Protocol, AH, security, IPv4, IPv6", + doi="10.17487/RFC1826", + } + +@misc{rfc1827, + author="R. Atkinson", + title="{IP Encapsulating Security Payload (ESP)}", + howpublished="RFC 1827 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1827", + pages="1--12", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2406", +url="https://www.rfc-editor.org/rfc/rfc1827.txt", + key="RFC 1827", + abstract={This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]}, + keywords="ESP, Internet, Protocol, IPv4, IPv6, ipsec", + doi="10.17487/RFC1827", + } + +@misc{rfc1828, + author="P. Metzger and W. Simpson", + title="{IP Authentication using Keyed MD5}", + howpublished="RFC 1828 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1828", + pages="1--6", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1828.txt", + key="RFC 1828", + abstract={This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK]}, + keywords="ipsec, Internet, Protocol, Authentication, Header, AH, Message, Digest, 5, Security", + doi="10.17487/RFC1828", + } + +@misc{rfc1829, + author="P. Karn and P. Metzger and W. Simpson", + title="{The ESP DES-CBC Transform}", + howpublished="RFC 1829 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1829", + pages="1--11", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1829.txt", + key="RFC 1829", + abstract={This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]}, + keywords="Encapsulating, Security, Payload, US, Data, Encryption, Standard, Cipher, Block, Chaining, IP, Internet, Protocol, Security, ipsec", + doi="10.17487/RFC1829", + } + +@misc{rfc1830, + author="G. Vaudreuil", + title="{SMTP Service Extensions for Transmission of Large and Binary MIME Messages}", + howpublished="RFC 1830 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1830", + pages="1--8", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3030", +url="https://www.rfc-editor.org/rfc/rfc1830.txt", + key="RFC 1830", + abstract={This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command ``BDAT'' for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community.}, + keywords="Simple, Mail, Transfer, Multipurpose, Mail, Extensions", + doi="10.17487/RFC1830", + } + +@misc{rfc1831, + author="R. Srinivasan", + title="{RPC: Remote Procedure Call Protocol Specification Version 2}", + howpublished="RFC 1831 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1831", + pages="1--18", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5531", +url="https://www.rfc-editor.org/rfc/rfc1831.txt", + key="RFC 1831", + abstract={This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]}, + keywords="RPC], ONC, Open, Network, Computing", + doi="10.17487/RFC1831", + } + +@misc{rfc1832, + author="R. Srinivasan", + title="{XDR: External Data Representation Standard}", + howpublished="RFC 1832 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1832", + pages="1--24", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4506", +url="https://www.rfc-editor.org/rfc/rfc1832.txt", + key="RFC 1832", + abstract={This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]}, + keywords="XDR, RPC, ONC, Open, Network, Computing", + doi="10.17487/RFC1832", + } + +@misc{rfc1833, + author="R. Srinivasan", + title="{Binding Protocols for ONC RPC Version 2}", + howpublished="RFC 1833 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1833", + pages="1--14", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5665", +url="https://www.rfc-editor.org/rfc/rfc1833.txt", + key="RFC 1833", + abstract={This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]}, + keywords="ONC, Open, Network, Computing", + doi="10.17487/RFC1833", + } + +@misc{rfc1834, + author="J. Gargano and K. Weiss", + title="{Whois and Network Information Lookup Service, Whois++}", + howpublished="RFC 1834 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1834", + pages="1--7", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1834.txt", + key="RFC 1834", + abstract={This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="nicname, TCP, Transmission, Control, Protocol, directory, service, server, retrieval", + doi="10.17487/RFC1834", + } + +@misc{rfc1835, + author="P. Deutsch and R. Schoultz and P. Faltstrom and C. Weider", + title="{Architecture of the WHOIS++ service}", + howpublished="RFC 1835 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1835", + pages="1--41", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1835.txt", + key="RFC 1835", + abstract={This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. [STANDARDS-TRACK]}, + keywords="WHOIS++, nicname, TCP, Transmission, Control, Protocol, directory, service, server, retrieval", + doi="10.17487/RFC1835", + } + +@misc{rfc1836, + author="S. Kille", + title="{Representing the O/R Address hierarchy in the X.500 Directory Information Tree}", + howpublished="RFC 1836 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1836", + pages="1--11", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2294", +url="https://www.rfc-editor.org/rfc/rfc1836.txt", + key="RFC 1836", + abstract={This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This memo defines an Experimental Protocol for the Internet community.}, + keywords="message, handling", + doi="10.17487/RFC1836", + } + +@misc{rfc1837, + author="S. Kille", + title="{Representing Tables and Subtrees in the X.500 Directory}", + howpublished="RFC 1837 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1837", + pages="1--7", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2293", +url="https://www.rfc-editor.org/rfc/rfc1837.txt", + key="RFC 1837", + abstract={This document defines techniques for representing two types of information mapping in the OSI Directory. This memo defines an Experimental Protocol for the Internet community.}, + keywords="message, handling", + doi="10.17487/RFC1837", + } + +@misc{rfc1838, + author="S. Kille", + title="{Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses}", + howpublished="RFC 1838 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1838", + pages="1--8", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2164", +url="https://www.rfc-editor.org/rfc/rfc1838.txt", + key="RFC 1838", + abstract={This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. This memo defines an Experimental Protocol for the Internet community.}, + keywords="message, handling", + doi="10.17487/RFC1838", + } + +@misc{rfc1841, + author="J. Chapman and D. Coli and A. Harvey and B. Jensen and K. Rowett", + title="{PPP Network Control Protocol for LAN Extension}", + howpublished="RFC 1841 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1841", + pages="1--66", + year=1995, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1841.txt", + key="RFC 1841", + keywords="point-to-point, local, area, interface,", + doi="10.17487/RFC1841", + } + +@misc{rfc1842, + author="Y. Wei and Y. Zhang and J. Li and J. Ding and Y. Jiang", + title="{ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages}", + howpublished="RFC 1842 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1842", + pages="1--12", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1842.txt", + key="RFC 1842", + abstract={This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="electronic, mail, HZ-GB-2312", + doi="10.17487/RFC1842", + } + +@misc{rfc1843, + author="F. Lee", + title="{HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters}", + howpublished="RFC 1843 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1843", + pages="1--5", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1843.txt", + key="RFC 1843", + abstract={The content of this memo is identical to an article of the same title written by the author on September 4, 1989. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="GB2312-80, electronic, mail", + doi="10.17487/RFC1843", + } + +@misc{rfc1844, + author="E. Huizer", + title="{Multimedia E-mail (MIME) User Agent Checklist}", + howpublished="RFC 1844 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1844", + pages="1--8", + year=1995, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1844.txt", + key="RFC 1844", + abstract={This document presents a checklist to facilitate evaluation of MIME capable User Agents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Multipurpose, Internet, Mail, Extensions, Media, Types", + doi="10.17487/RFC1844", + } + +@misc{rfc1845, + author="D. Crocker and N. Freed and A. Cargille", + title="{SMTP Service Extension for Checkpoint/Restart}", + howpublished="RFC 1845 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1845", + pages="1--7", + year=1995, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1845.txt", + key="RFC 1845", + keywords="simple, mail, transfer, transaction", + doi="10.17487/RFC1845", + } + +@misc{rfc1846, + author="A. Durand and F. Dupont", + title="{SMTP 521 Reply Code}", + howpublished="RFC 1846 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1846", + pages="1--4", + year=1995, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7504", +url="https://www.rfc-editor.org/rfc/rfc1846.txt", + key="RFC 1846", + keywords="simple, mail, transfer", + doi="10.17487/RFC1846", + } + +@misc{rfc1847, + author="J. Galvin and S. Murphy and S. Crocker and N. Freed", + title="{Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted}", + howpublished="RFC 1847 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1847", + pages="1--11", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1847.txt", + key="RFC 1847", + abstract={This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MIME-Encyp, mail, multipurpose, extensions", + doi="10.17487/RFC1847", + } + +@misc{rfc1848, + author="S. Crocker and N. Freed and J. Galvin and S. Murphy", + title="{MIME Object Security Services}", + howpublished="RFC 1848 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1848", + pages="1--48", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1848.txt", + key="RFC 1848", + abstract={This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. [STANDARDS-TRACK]}, + keywords="MIME-Sec, mail, multipurpose, extensions", + doi="10.17487/RFC1848", + } + +@misc{rfc1849, + author="H. Spencer", + title="{``Son of 1036'': News Article Format and Transmission}", + howpublished="RFC 1849 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1849", + pages="1--106", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5536, 5537", +url="https://www.rfc-editor.org/rfc/rfc1849.txt", + key="RFC 1849", + abstract={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. 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.}, + keywords="netnews, usenet, rfc 1036, usefor, historic", + doi="10.17487/RFC1849", + } + +@misc{rfc1850, + author="F. Baker and R. Coltun", + title="{OSPF Version 2 Management Information Base}", + howpublished="RFC 1850 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1850", + pages="1--80", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4750", +url="https://www.rfc-editor.org/rfc/rfc1850.txt", + key="RFC 1850", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]}, + keywords="OSPF-MIB, Open, Shortest, Path, First, SPF, MIB, routing, network management", + doi="10.17487/RFC1850", + } + +@misc{rfc1851, + author="P. Karn and P. Metzger and W. Simpson", + title="{The ESP Triple DES Transform}", + howpublished="RFC 1851 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1851", + pages="1--11", + year=1995, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1851.txt", + key="RFC 1851", + keywords="ESP3DES, encryption encapsulating security payload cipher block chaining", + doi="10.17487/RFC1851", + } + +@misc{rfc1852, + author="P. Metzger and W. Simpson", + title="{IP Authentication using Keyed SHA}", + howpublished="RFC 1852 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1852", + pages="1--6", + year=1995, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2841", +url="https://www.rfc-editor.org/rfc/rfc1852.txt", + key="RFC 1852", + keywords="encryption secure hash algorithm", + doi="10.17487/RFC1852", + } + +@misc{rfc1853, + author="W. Simpson", + title="{IP in IP Tunneling}", + howpublished="RFC 1853 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1853", + pages="1--8", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1853.txt", + key="RFC 1853", + abstract={This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes the use of keyed SHA with the IP Authentication Header. This document defines an Experimental Protocol for the Internet community. This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). This document defines an Experimental Protocol for the Internet community.}, + keywords="internet protocol payload encapsulation", + doi="10.17487/RFC1853", + } + +@misc{rfc1854, + author="N. Freed", + title="{SMTP Service Extension for Command Pipelining}", + howpublished="RFC 1854 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1854", + pages="1--7", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2197", +url="https://www.rfc-editor.org/rfc/rfc1854.txt", + key="RFC 1854", + abstract={This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]}, + keywords="simple mail transfer protocol", + doi="10.17487/RFC1854", + } + +@misc{rfc1855, + author="S. Hambridge", + title="{Netiquette Guidelines}", + howpublished="RFC 1855 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1855", + pages="1--21", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1855.txt", + key="RFC 1855", + abstract={This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Network, Etiquette", + doi="10.17487/RFC1855", + } + +@misc{rfc1856, + author="H. Clark", + title="{The Opstat Client-Server Model for Statistics Retrieval}", + howpublished="RFC 1856 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1856", + pages="1--17", + year=1995, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1856.txt", + key="RFC 1856", + keywords="tools, performance, utilization", + doi="10.17487/RFC1856", + } + +@misc{rfc1857, + author="M. Lambert", + title="{A Model for Common Operational Statistics}", + howpublished="RFC 1857 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1857", + pages="1--27", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1857.txt", + key="RFC 1857", + abstract={This memo describes a model for operational statistics in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="metrics, measurements, polling periods", + doi="10.17487/RFC1857", + } + +@misc{rfc1858, + author="G. Ziemba and D. Reed and P. Traina", + title="{Security Considerations for IP Fragment Filtering}", + howpublished="RFC 1858 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1858", + pages="1--10", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3128", +url="https://www.rfc-editor.org/rfc/rfc1858.txt", + key="RFC 1858", + abstract={IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="internet, protocol, tcp, transmission, control, protocol, routers, hosts", + doi="10.17487/RFC1858", + } + +@misc{rfc1859, + author="Y. Pouffary", + title="{ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension}", + howpublished="RFC 1859 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1859", + pages="1--8", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1859.txt", + key="RFC 1859", + abstract={This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="International, Standard, Organizatio", + doi="10.17487/RFC1859", + } + +@misc{rfc1860, + author="T. Pummill and B. Manning", + title="{Variable Length Subnet Table For IPv4}", + howpublished="RFC 1860 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1860", + pages="1--3", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1878", +url="https://www.rfc-editor.org/rfc/rfc1860.txt", + key="RFC 1860", + abstract={This document itemizes the potential values for IPv4 subnets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="values, IPv4, subnets", + doi="10.17487/RFC1860", + } + +@misc{rfc1861, + author="A. Gwinn", + title="{Simple Network Paging Protocol - Version 3 -Two-Way Enhanced}", + howpublished="RFC 1861 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1861", + pages="1--23", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1861.txt", + key="RFC 1861", + abstract={This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="SNPP, SNPP, wireless, paging", + doi="10.17487/RFC1861", + } + +@misc{rfc1862, + author="M. McCahill and J. Romkey and M. Schwartz and K. Sollins and T. Verschuren and C. Weider", + title="{Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994}", + howpublished="RFC 1862 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1862", + pages="1--27", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1862.txt", + key="RFC 1862", + abstract={This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Architecture, Board", + doi="10.17487/RFC1862", + } + +@misc{rfc1863, + author="D. Haskin", + title="{A BGP/IDRP Route Server alternative to a full mesh routing}", + howpublished="RFC 1863 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1863", + pages="1--16", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4223", +url="https://www.rfc-editor.org/rfc/rfc1863.txt", + key="RFC 1863", + abstract={This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers. This memo defines an Experimental Protocol for the Internet community.}, + keywords="BGP-IDRP, border, gateway, protocol, inter-domain, routing", + doi="10.17487/RFC1863", + } + +@misc{rfc1864, + author="J. Myers and M. Rose", + title="{The Content-MD5 Header Field}", + howpublished="RFC 1864 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1864", + pages="1--4", + year=1995, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1864.txt", + key="RFC 1864", + abstract={This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]}, + keywords="CON-MD5, MIME, EMail, Integrity, MIC, Digest", + doi="10.17487/RFC1864", + } + +@misc{rfc1865, + author="W. Houser and J. Griffin and C. Hage", + title="{EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet}", + howpublished="RFC 1865 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1865", + pages="1--41", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1865.txt", + key="RFC 1865", + abstract={This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="FAQ", + doi="10.17487/RFC1865", + } + +@misc{rfc1866, + author="T. Berners-Lee and D. Connolly", + title="{Hypertext Markup Language - 2.0}", + howpublished="RFC 1866 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1866", + pages="1--77", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2854", +url="https://www.rfc-editor.org/rfc/rfc1866.txt", + key="RFC 1866", + abstract={This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK]}, + keywords="HTML, HTML, SGML, Standard, Generalized, Language, WWW, World, Wide, Web", + doi="10.17487/RFC1866", + } + +@misc{rfc1867, + author="E. Nebel and L. Masinter", + title="{Form-based File Upload in HTML}", + howpublished="RFC 1867 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1867", + pages="1--13", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2854", +url="https://www.rfc-editor.org/rfc/rfc1867.txt", + key="RFC 1867", + abstract={Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community.}, + keywords="Hypertext, Markup, Language, MIME, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1867", + } + +@misc{rfc1868, + author="G. Malkin", + title="{ARP Extension - UNARP}", + howpublished="RFC 1868 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1868", + pages="1--4", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1868.txt", + key="RFC 1868", + abstract={This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. This memo defines an Experimental Protocol for the Internet community.}, + keywords="UNARP, Address, Resolution, Protocol, delete, entry", + doi="10.17487/RFC1868", + } + +@misc{rfc1869, + author="J. Klensin and N. Freed and M. Rose and E. Stefferud and D. Crocker", + title="{SMTP Service Extensions}", + howpublished="RFC 1869 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1869", + pages="1--11", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2821", +url="https://www.rfc-editor.org/rfc/rfc1869.txt", + key="RFC 1869", + abstract={This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]}, + keywords="ESMTP, Simple, Mail, Transfer, Protocol", + doi="10.17487/RFC1869", + } + +@misc{rfc1870, + author="J. Klensin and N. Freed and K. Moore", + title="{SMTP Service Extension for Message Size Declaration}", + howpublished="RFC 1870 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1870", + pages="1--9", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1870.txt", + key="RFC 1870", + abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]}, + keywords="SMTP-SIZE, Simple Mail Transfer Protocol", + doi="10.17487/RFC1870", + } + +@misc{rfc1871, + author="J. Postel", + title="{Addendum to RFC 1602 -- Variance Procedure}", + howpublished="RFC 1871 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1871", + pages="1--4", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2026", +url="https://www.rfc-editor.org/rfc/rfc1871.txt", + key="RFC 1871", + abstract={This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="BCP, WG, escape, clause, procedures", + doi="10.17487/RFC1871", + } + +@misc{rfc1872, + author="E. Levinson", + title="{The MIME Multipart/Related Content-type}", + howpublished="RFC 1872 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1872", + pages="1--8", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2112", +url="https://www.rfc-editor.org/rfc/rfc1872.txt", + key="RFC 1872", + abstract={The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. This memo defines an Experimental Protocol for the Internet community.}, + keywords="multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1872", + } + +@misc{rfc1873, + author="E. Levinson", + title="{Message/External-Body Content-ID Access Type}", + howpublished="RFC 1873 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1873", + pages="1--4", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1873.txt", + key="RFC 1873", + abstract={The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. This memo defines an Experimental Protocol for the Internet community.}, + keywords="CONT-MT, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1873", + } + +@misc{rfc1874, + author="E. Levinson", + title="{SGML Media Types}", + howpublished="RFC 1874 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1874", + pages="1--6", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1874.txt", + key="RFC 1874", + abstract={This document proposes new media sub-types of Text/SGML and Application/SGML. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SGML-MT, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1874", + } + +@misc{rfc1875, + author="N. Berge", + title="{UNINETT PCA Policy Statements}", + howpublished="RFC 1875 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1875", + pages="1--10", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1875.txt", + key="RFC 1875", + abstract={This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Policy, Certification, Authority, Encryption", + doi="10.17487/RFC1875", + } + +@misc{rfc1876, + author="C. Davis and P. Vixie and T. Goodwin and I. Dickinson", + title="{A Means for Expressing Location Information in the Domain Name System}", + howpublished="RFC 1876 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1876", + pages="1--18", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1876.txt", + key="RFC 1876", + abstract={This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DNS-LOC, DNS, Resource, Record, (RR), LOC", + doi="10.17487/RFC1876", + } + +@misc{rfc1877, + author="S. Cobb", + title="{PPP Internet Protocol Control Protocol Extensions for Name Server Addresses}", + howpublished="RFC 1877 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1877", + pages="1--6", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1877.txt", + key="RFC 1877", + abstract={This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Point-to-Point, Protocol, Network, Control, Domain, System, NetBIOS", + doi="10.17487/RFC1877", + } + +@misc{rfc1878, + author="T. Pummill and B. Manning", + title="{Variable Length Subnet Table For IPv4}", + howpublished="RFC 1878 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1878", + pages="1--8", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1878.txt", + key="RFC 1878", + abstract={This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="values, IPv4, subnets", + doi="10.17487/RFC1878", + } + +@misc{rfc1879, + author="B. {Manning (Ed.)}", + title="{Class A Subnet Experiment Results and Recommendations}", + howpublished="RFC 1879 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1879", + pages="1--6", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1879.txt", + key="RFC 1879", + abstract={This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Registry, Operations", + doi="10.17487/RFC1879", + } + +@misc{rfc1880, + author="J. {Postel (Ed.)}", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1880 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1880", + pages="1--38", + year=1995, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 1920", +url="https://www.rfc-editor.org/rfc/rfc1880.txt", + key="RFC 1880", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1880", + } + +@misc{rfc1881, + author="IAB and IESG", + title="{IPv6 Address Allocation Management}", + howpublished="RFC 1881 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1881", + pages="1--2", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1881.txt", + key="RFC 1881", + abstract={The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IANA, Internet, Assigned, Numbers, Authority", + doi="10.17487/RFC1881", + } + +@misc{rfc1882, + author="B. Hancock", + title="{The 12-Days of Technology Before Christmas}", + howpublished="RFC 1882 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1882", + pages="1--5", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1882.txt", + key="RFC 1882", + abstract={This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1882", + } + +@misc{rfc1883, + author="S. Deering and R. Hinden", + title="{Internet Protocol, Version 6 (IPv6) Specification}", + howpublished="RFC 1883 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1883", + pages="1--37", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2460", +url="https://www.rfc-editor.org/rfc/rfc1883.txt", + key="RFC 1883", + abstract={This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]}, + keywords="IP, Next, Generation, IPng", + doi="10.17487/RFC1883", + } + +@misc{rfc1884, + author="R. {Hinden (Ed.)} and S. {Deering (Ed.)}", + title="{IP Version 6 Addressing Architecture}", + howpublished="RFC 1884 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1884", + pages="1--18", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2373", +url="https://www.rfc-editor.org/rfc/rfc1884.txt", + key="RFC 1884", + abstract={This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]}, + keywords="IPV6-Addr, IP, Next, Generation, IPng", + doi="10.17487/RFC1884", + } + +@misc{rfc1885, + author="A. Conta and S. Deering", + title="{Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)}", + howpublished="RFC 1885 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1885", + pages="1--20", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2463", +url="https://www.rfc-editor.org/rfc/rfc1885.txt", + key="RFC 1885", + abstract={This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]}, + keywords="IP, Next, Generation, IPng, Internet, Group, Management, IGMP", + doi="10.17487/RFC1885", + } + +@misc{rfc1886, + author="S. Thomson and C. Huitema", + title="{DNS Extensions to support IP version 6}", + howpublished="RFC 1886 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1886", + pages="1--5", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3596, updated by RFCs 2874, 3152", +url="https://www.rfc-editor.org/rfc/rfc1886.txt", + key="RFC 1886", + abstract={This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK]}, + keywords="DNS-IPV6, IP, Next, Generation, IPng, Domain, Name, System", + doi="10.17487/RFC1886", + } + +@misc{rfc1887, + author="Y. {Rekhter (Ed.)} and T. {Li (Ed.)}", + title="{An Architecture for IPv6 Unicast Address Allocation}", + howpublished="RFC 1887 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1887", + pages="1--26", + year=1995, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1887.txt", + key="RFC 1887", + abstract={This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, Next, Generation, IPng,", + doi="10.17487/RFC1887", + } + +@misc{rfc1888, + author="J. Bound and B. Carpenter and D. Harrington and J. Houldsworth and A. Lloyd", + title="{OSI NSAPs and IPv6}", + howpublished="RFC 1888 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1888", + pages="1--16", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4048, updated by RFC 4548", +url="https://www.rfc-editor.org/rfc/rfc1888.txt", + key="RFC 1888", + abstract={This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. This memo defines an Experimental Protocol for the Internet community.}, + keywords="Internet, Protocol, Open, Systems, Interconnection", + doi="10.17487/RFC1888", + } + +@misc{rfc1889, + author="Audio-Video Transport Working Group and H. Schulzrinne and S. Casner and R. Frederick and V. Jacobson", + title="{RTP: A Transport Protocol for Real-Time Applications}", + howpublished="RFC 1889 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1889", + pages="1--75", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3550", +url="https://www.rfc-editor.org/rfc/rfc1889.txt", + key="RFC 1889", + abstract={This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. [STANDARDS-TRACK]}, + keywords="RTP, end-to-end, network, audio, video, RTCP", + doi="10.17487/RFC1889", + } + +@misc{rfc1890, + author="Audio-Video Transport Working Group and H. Schulzrinne", + title="{RTP Profile for Audio and Video Conferences with Minimal Control}", + howpublished="RFC 1890 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1890", + pages="1--18", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3551", +url="https://www.rfc-editor.org/rfc/rfc1890.txt", + key="RFC 1890", + abstract={This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. [STANDARDS-TRACK]}, + keywords="RTP-AV, end-to-end, network, conference", + doi="10.17487/RFC1890", + } + +@misc{rfc1891, + author="K. Moore", + title="{SMTP Service Extension for Delivery Status Notifications}", + howpublished="RFC 1891 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1891", + pages="1--31", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3461", +url="https://www.rfc-editor.org/rfc/rfc1891.txt", + key="RFC 1891", + abstract={This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]}, + keywords="SMTP-DSN, simple, mail, transfer, protocol", + doi="10.17487/RFC1891", + } + +@misc{rfc1892, + author="G. Vaudreuil", + title="{The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages}", + howpublished="RFC 1892 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1892", + pages="1--4", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3462", +url="https://www.rfc-editor.org/rfc/rfc1892.txt", + key="RFC 1892", + abstract={The Multipart/Report MIME content-type is a general ``family'' or ``container'' type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]}, + keywords="MIME-RPT, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1892", + } + +@misc{rfc1893, + author="G. Vaudreuil", + title="{Enhanced Mail System Status Codes}", + howpublished="RFC 1893 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1893", + pages="1--15", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3463", +url="https://www.rfc-editor.org/rfc/rfc1893.txt", + key="RFC 1893", + abstract={There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]}, + keywords="EMS-CODE, simple, mail, transfer, protocol, SMTP", + doi="10.17487/RFC1893", + } + +@misc{rfc1894, + author="K. Moore and G. Vaudreuil", + title="{An Extensible Message Format for Delivery Status Notifications}", + howpublished="RFC 1894 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1894", + pages="1--39", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3464, updated by RFC 2852", +url="https://www.rfc-editor.org/rfc/rfc1894.txt", + key="RFC 1894", + abstract={This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS-TRACK]}, + keywords="DSN, Multipurpose, Internet, Mail, Extensions, Content, Type", + doi="10.17487/RFC1894", + } + +@misc{rfc1895, + author="E. Levinson", + title="{The Application/CALS-1840 Content-type}", + howpublished="RFC 1895 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1895", + pages="1--6", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1895.txt", + key="RFC 1895", + abstract={This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, ``Automated Interchange of Technical Information,'' with the Internet electronic mail standards, RFC 822 and RFC 1521. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="MIL-STD-1840, MIME, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1895", + } + +@misc{rfc1896, + author="P. Resnick and A. Walker", + title="{The text/enriched MIME Content-type}", + howpublished="RFC 1896 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1896", + pages="1--21", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1896.txt", + key="RFC 1896", + abstract={This document defines one particular type of MIME data, the text/enriched MIME type. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="MIME, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC1896", + } + +@misc{rfc1897, + author="R. Hinden and J. Postel", + title="{IPv6 Testing Address Allocation}", + howpublished="RFC 1897 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1897", + pages="1--4", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2471", +url="https://www.rfc-editor.org/rfc/rfc1897.txt", + key="RFC 1897", + abstract={This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community.}, + keywords="Internet, Protocol, prototype, software", + doi="10.17487/RFC1897", + } + +@misc{rfc1898, + author="D. {Eastlake 3rd} and B. Boesch and S. Crocker and M. Yesil", + title="{CyberCash Credit Card Protocol Version 0.8}", + howpublished="RFC 1898 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1898", + pages="1--52", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1898.txt", + key="RFC 1898", + abstract={This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="general, payments, system", + doi="10.17487/RFC1898", + } + +@misc{rfc1899, + author="J. Elliott", + title="{Request for Comments Summary RFC Numbers 1800-1899}", + howpublished="RFC 1899 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1899", + pages="1--20", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1899.txt", + key="RFC 1899", + keywords="Index", + doi="10.17487/RFC1899", + } + +@misc{rfc1900, + author="B. Carpenter and Y. Rekhter", + title="{Renumbering Needs Work}", + howpublished="RFC 1900 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1900", + pages="1--4", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1900.txt", + key="RFC 1900", + abstract={Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols. A change in such IP addressing information associated with a host or subnet is known as ``renumbering''. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, network, number, addressing", + doi="10.17487/RFC1900", + } + +@misc{rfc1901, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Introduction to Community-based SNMPv2}", + howpublished="RFC 1901 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1901", + pages="1--8", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1901.txt", + key="RFC 1901", + abstract={The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.}, + keywords="SNMPV2CB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1901", + } + +@misc{rfc1902, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1902 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1902", + pages="1--40", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2578", +url="https://www.rfc-editor.org/rfc/rfc1902.txt", + key="RFC 1902", + abstract={It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]}, + keywords="Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1902", + } + +@misc{rfc1903, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1903 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1903", + pages="1--23", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2579", +url="https://www.rfc-editor.org/rfc/rfc1903.txt", + key="RFC 1903", + abstract={It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]}, + keywords="Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1903", + } + +@misc{rfc1904, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1904 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1904", + pages="1--24", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2580", +url="https://www.rfc-editor.org/rfc/rfc1904.txt", + key="RFC 1904", + abstract={It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]}, + keywords="Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1904", + } + +@misc{rfc1905, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1905 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1905", + pages="1--24", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3416", +url="https://www.rfc-editor.org/rfc/rfc1905.txt", + key="RFC 1905", + abstract={It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]}, + keywords="OPS-MIB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1905", + } + +@misc{rfc1906, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1906 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1906", + pages="1--13", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3417", +url="https://www.rfc-editor.org/rfc/rfc1906.txt", + key="RFC 1906", + abstract={It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]}, + keywords="TRANS-MIB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1906", + } + +@misc{rfc1907, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)}", + howpublished="RFC 1907 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1907", + pages="1--20", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3418", +url="https://www.rfc-editor.org/rfc/rfc1907.txt", + key="RFC 1907", + abstract={It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]}, + keywords="SNMPv2-MIB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1907", + } + +@misc{rfc1908, + author="J. Case and K. McCloghrie and M. Rose and S. Waldbusser", + title="{Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework}", + howpublished="RFC 1908 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1908", + pages="1--10", + year=1996, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2576", +url="https://www.rfc-editor.org/rfc/rfc1908.txt", + key="RFC 1908", + abstract={The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]}, + keywords="COEX-MIB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1908", + } + +@misc{rfc1909, + author="K. {McCloghrie (Ed.)}", + title="{An Administrative Infrastructure for SNMPv2}", + howpublished="RFC 1909 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1909", + pages="1--19", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1909.txt", + key="RFC 1909", + abstract={It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SNMPV2AI, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1909", + } + +@misc{rfc1910, + author="G. {Waters (Ed.)}", + title="{User-based Security Model for SNMPv2}", + howpublished="RFC 1910 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1910", + pages="1--44", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1910.txt", + key="RFC 1910", + abstract={In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SNMPV2SM, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC1910", + } + +@misc{rfc1911, + author="G. Vaudreuil", + title="{Voice Profile for Internet Mail}", + howpublished="RFC 1911 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1911", + pages="1--22", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 2421, 2422, 2423", +url="https://www.rfc-editor.org/rfc/rfc1911.txt", + key="RFC 1911", + abstract={The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MIME, Multipurpose, Internet, Mail, Extensions, ESMTP, SMTP, Service, Extensions", + doi="10.17487/RFC1911", + } + +@misc{rfc1912, + author="D. Barr", + title="{Common DNS Operational and Configuration Errors}", + howpublished="RFC 1912 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1912", + pages="1--16", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1912.txt", + key="RFC 1912", + abstract={This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Domain, Name, System", + doi="10.17487/RFC1912", + } + +@misc{rfc1913, + author="C. Weider and J. Fullton and S. Spero", + title="{Architecture of the Whois++ Index Service}", + howpublished="RFC 1913 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1913", + pages="1--16", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1913.txt", + key="RFC 1913", + abstract={The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK]}, + keywords="WHOIS++A, Bunyip Information Systems, Inc., MCNC Center for Communications", + doi="10.17487/RFC1913", + } + +@misc{rfc1914, + author="P. Faltstrom and R. Schoultz and C. Weider", + title="{How to Interact with a Whois++ Mesh}", + howpublished="RFC 1914 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1914", + pages="1--10", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1914.txt", + key="RFC 1914", + abstract={In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]}, + keywords="WHOIS++M, distributed, databases, directory, service", + doi="10.17487/RFC1914", + } + +@misc{rfc1915, + author="F. Kastenholz", + title="{Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol}", + howpublished="RFC 1915 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="1915", + pages="1--7", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1915.txt", + key="RFC 1915", + abstract={The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Point, to, Point, Protocol", + doi="10.17487/RFC1915", + } + +@misc{rfc1916, + author="H. Berkowitz and P. Ferguson and W. Leland and P. Nesser", + title="{Enterprise Renumbering: Experience and Information Solicitation}", + howpublished="RFC 1916 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1916", + pages="1--8", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1916.txt", + key="RFC 1916", + abstract={Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="tools, applications", + doi="10.17487/RFC1916", + } + +@misc{rfc1917, + author="P. Nesser II", + title="{An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA}", + howpublished="RFC 1917 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="1917", + pages="1--10", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1917.txt", + key="RFC 1917", + abstract={This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="address, space, Internet, Assigned, Numbers, Authority, IANA", + doi="10.17487/RFC1917", + } + +@misc{rfc1918, + author="Y. Rekhter and B. Moskowitz and D. Karrenberg and G. J. de Groot and E. Lear", + title="{Address Allocation for Private Internets}", + howpublished="RFC 1918 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="1918", + pages="1--9", + year=1996, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6761", +url="https://www.rfc-editor.org/rfc/rfc1918.txt", + key="RFC 1918", + abstract={This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="TCP/IP, network, host", + doi="10.17487/RFC1918", + } + +@misc{rfc1919, + author="M. Chatel", + title="{Classical versus Transparent IP Proxies}", + howpublished="RFC 1919 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1919", + pages="1--35", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1919.txt", + key="RFC 1919", + abstract={This document explains ``classical'' and ``transparent'' proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="firewalls, security", + doi="10.17487/RFC1919", + } + +@misc{rfc1920, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 1920 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1920", + pages="1--40", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2000", +url="https://www.rfc-editor.org/rfc/rfc1920.txt", + key="RFC 1920", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]}, + keywords="status, procedure, index", + doi="10.17487/RFC1920", + } + +@misc{rfc1921, + author="J. Dujonc", + title="{TNVIP Protocol}", + howpublished="RFC 1921 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1921", + pages="1--30", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1921.txt", + key="RFC 1921", + abstract={The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC1921", + } + +@misc{rfc1922, + author="HF. Zhu and DY. Hu and ZG. Wang and TC. Kao and WCH. Chang and M. Crispin", + title="{Chinese Character Encoding for Internet Messages}", + howpublished="RFC 1922 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1922", + pages="1--27", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1922.txt", + key="RFC 1922", + abstract={This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866]. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="transport, electronic, mail, telnet, WWW", + doi="10.17487/RFC1922", + } + +@misc{rfc1923, + author="J. Halpern and S. Bradner", + title="{RIPv1 Applicability Statement for Historic Status}", + howpublished="RFC 1923 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1923", + pages="1--3", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1923.txt", + key="RFC 1923", + abstract={RIP Version 1 [RFC-1058] has been declared an historic document. This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is the Classful nature of RIPv1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Routing, Information, Protocol", + doi="10.17487/RFC1923", + } + +@misc{rfc1924, + author="R. Elz", + title="{A Compact Representation of IPv6 Addresses}", + howpublished="RFC 1924 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1924", + pages="1--6", + year=1996, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1924.txt", + key="RFC 1924", + abstract={This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="encoding", + doi="10.17487/RFC1924", + } + +@misc{rfc1925, + author="R. Callon", + title="{The Twelve Networking Truths}", + howpublished="RFC 1925 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1925", + pages="1--3", + year=1996, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1925.txt", + key="RFC 1925", + abstract={This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="fundamentals", + doi="10.17487/RFC1925", + } + +@misc{rfc1926, + author="J. Eriksson", + title="{An Experimental Encapsulation of IP Datagrams on Top of ATM}", + howpublished="RFC 1926 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1926", + pages="1--2", + year=1996, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1926.txt", + key="RFC 1926", + abstract={This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Acoustical, Transmission, Media (ATM)", + doi="10.17487/RFC1926", + } + +@misc{rfc1927, + author="C. Rogers", + title="{Suggested Additional MIME Types for Associating Documents}", + howpublished="RFC 1927 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1927", + pages="1--3", + year=1996, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1927.txt", + key="RFC 1927", + abstract={Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="media-type", + doi="10.17487/RFC1927", + } + +@misc{rfc1928, + author="M. Leech and M. Ganis and Y. Lee and R. Kuris and D. Koblas and L. Jones", + title="{SOCKS Protocol Version 5}", + howpublished="RFC 1928 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1928", + pages="1--9", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1928.txt", + key="RFC 1928", + abstract={This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]}, + keywords="SOCKSV5, firewalls, authentication", + doi="10.17487/RFC1928", + } + +@misc{rfc1929, + author="M. Leech", + title="{Username/Password Authentication for SOCKS V5}", + howpublished="RFC 1929 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1929", + pages="1--2", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1929.txt", + key="RFC 1929", + abstract={The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication ``subnegotiation''. [STANDARDS-TRACK]}, + keywords="AUTH-SOCKS, firewalls, authentication", + doi="10.17487/RFC1929", + } + +@misc{rfc1930, + author="J. Hawkinson and T. Bates", + title="{Guidelines for creation, selection, and registration of an Autonomous System (AS)}", + howpublished="RFC 1930 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="1930", + pages="1--10", + year=1996, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6996, 7300", +url="https://www.rfc-editor.org/rfc/rfc1930.txt", + key="RFC 1930", + abstract={This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="routing, policy, Exterior, Gateway, Protocol, Border, Inter-Domain, Domain, Identifier, EGP, BGP, IDRP", + doi="10.17487/RFC1930", + } + +@misc{rfc1931, + author="D. Brownell", + title="{Dynamic RARP Extensions for Automatic Network Address Acquisition}", + howpublished="RFC 1931 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1931", + pages="1--11", + year=1996, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1931.txt", + key="RFC 1931", + abstract={This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind.}, + keywords="Reverse, Address, Resolution, Protocol", + doi="10.17487/RFC1931", + } + +@misc{rfc1932, + author="R. Cole and D. Shur and C. Villamizar", + title="{IP over ATM: A Framework Document}", + howpublished="RFC 1932 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1932", + pages="1--31", + year=1996, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1932.txt", + key="RFC 1932", + abstract={It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="end-to-end, connectivity", + doi="10.17487/RFC1932", + } + +@misc{rfc1933, + author="R. Gilligan and E. Nordmark", + title="{Transition Mechanisms for IPv6 Hosts and Routers}", + howpublished="RFC 1933 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1933", + pages="1--22", + year=1996, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2893", +url="https://www.rfc-editor.org/rfc/rfc1933.txt", + key="RFC 1933", + abstract={This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]}, + keywords="TRANS-IPV6, IPv4", + doi="10.17487/RFC1933", + } + +@misc{rfc1934, + author="K. Smith", + title="{Ascend's Multilink Protocol Plus (MP+)}", + howpublished="RFC 1934 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1934", + pages="1--47", + year=1996, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1934.txt", + key="RFC 1934", + abstract={This document proposes an extension to the PPP Multilink Protocol (MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP", + doi="10.17487/RFC1934", + } + +@misc{rfc1935, + author="J. Quarterman and S. Carl-Mitchell", + title="{What is the Internet, Anyway?}", + howpublished="RFC 1935 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1935", + pages="1--11", + year=1996, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1935.txt", + key="RFC 1935", + abstract={This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="information, tutorial", + doi="10.17487/RFC1935", + } + +@misc{rfc1936, + author="J. Touch and B. Parham", + title="{Implementing the Internet Checksum in Hardware}", + howpublished="RFC 1936 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1936", + pages="1--21", + year=1996, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1936.txt", + key="RFC 1936", + abstract={This memo presents a techniques for efficiently implementing the Internet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PLD, code, UDP, TCP", + doi="10.17487/RFC1936", + } + +@misc{rfc1937, + author="Y. Rekhter and D. Kandlur", + title="{``Local/Remote'' Forwarding Decision in Switched Data Link Subnetworks}", + howpublished="RFC 1937 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1937", + pages="1--8", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1937.txt", + key="RFC 1937", + abstract={This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, subnet", + doi="10.17487/RFC1937", + } + +@misc{rfc1938, + author="N. Haller and C. Metz", + title="{A One-Time Password System}", + howpublished="RFC 1938 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1938", + pages="1--18", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2289", +url="https://www.rfc-editor.org/rfc/rfc1938.txt", + key="RFC 1938", + abstract={This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]}, + keywords="OTP, authentication, S/KEY", + doi="10.17487/RFC1938", + } + +@misc{rfc1939, + author="J. Myers and M. Rose", + title="{Post Office Protocol - Version 3}", + howpublished="RFC 1939 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="1939", + pages="1--23", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 1957, 2449, 6186, 8314", +url="https://www.rfc-editor.org/rfc/rfc1939.txt", + key="RFC 1939", + abstract={The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]}, + keywords="POP3, POP3", + doi="10.17487/RFC1939", + } + +@misc{rfc1940, + author="D. Estrin and T. Li and Y. Rekhter and K. Varadhan and D. Zappala", + title="{Source Demand Routing: Packet Format and Forwarding Specification (Version 1)}", + howpublished="RFC 1940 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1940", + pages="1--27", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1940.txt", + key="RFC 1940", + abstract={The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="SDRP", + doi="10.17487/RFC1940", + } + +@misc{rfc1941, + author="J. Sellers and J. Robichaux", + title="{Frequently Asked Questions for Schools}", + howpublished="RFC 1941 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1941", + pages="1--70", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1941.txt", + key="RFC 1941", + abstract={The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="FAQ, Internet, Education", + doi="10.17487/RFC1941", + } + +@misc{rfc1942, + author="D. Raggett", + title="{HTML Tables}", + howpublished="RFC 1942 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1942", + pages="1--30", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2854", +url="https://www.rfc-editor.org/rfc/rfc1942.txt", + key="RFC 1942", + abstract={This specification extends HTML to support a wide variety of tables. This memo defines an Experimental Protocol for the Internet community.}, + keywords="HTML-TBL, HyperText, Markup, Language, SGML", + doi="10.17487/RFC1942", + } + +@misc{rfc1943, + author="B. Jennings", + title="{Building an X.500 Directory Service in the US}", + howpublished="RFC 1943 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1943", + pages="1--22", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1943.txt", + key="RFC 1943", + abstract={This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="White, Pages", + doi="10.17487/RFC1943", + } + +@misc{rfc1944, + author="S. Bradner and J. McQuaid", + title="{Benchmarking Methodology for Network Interconnect Devices}", + howpublished="RFC 1944 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1944", + pages="1--30", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2544", +url="https://www.rfc-editor.org/rfc/rfc1944.txt", + key="RFC 1944", + abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="testing, performance", + doi="10.17487/RFC1944", + } + +@misc{rfc1945, + author="T. Berners-Lee and R. Fielding and H. Frystyk", + title="{Hypertext Transfer Protocol -- HTTP/1.0}", + howpublished="RFC 1945 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1945", + pages="1--60", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1945.txt", + key="RFC 1945", + abstract={The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="HTTP-1.0, HTTP, World-Wide, Web, application", + doi="10.17487/RFC1945", + } + +@misc{rfc1946, + author="S. Jackowski", + title="{Native ATM Support for ST2+}", + howpublished="RFC 1946 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1946", + pages="1--21", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1946.txt", + key="RFC 1946", + abstract={This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: ATM to internet, internet to ATM, and internet to internet across ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="integrated, services, ATM, Quality, of, Service, QoS", + doi="10.17487/RFC1946", + } + +@misc{rfc1947, + author="D. Spinellis", + title="{Greek Character Encoding for Electronic Mail Messages}", + howpublished="RFC 1947 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1947", + pages="1--7", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1947.txt", + key="RFC 1947", + abstract={This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="character, set, ISO, MIME", + doi="10.17487/RFC1947", + } + +@misc{rfc1948, + author="S. Bellovin", + title="{Defending Against Sequence Number Attacks}", + howpublished="RFC 1948 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1948", + pages="1--6", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6528", +url="https://www.rfc-editor.org/rfc/rfc1948.txt", + key="RFC 1948", + abstract={IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="crypgraphic, authentication, spoofing", + doi="10.17487/RFC1948", + } + +@misc{rfc1949, + author="A. Ballardie", + title="{Scalable Multicast Key Distribution}", + howpublished="RFC 1949 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1949", + pages="1--18", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1949.txt", + key="RFC 1949", + abstract={This memo provides a scalable solution to the multicast key distribution problem. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SMKD, MBONE, security, authentication", + doi="10.17487/RFC1949", + } + +@misc{rfc1950, + author="P. Deutsch and J-L. Gailly", + title="{ZLIB Compressed Data Format Specification version 3.3}", + howpublished="RFC 1950 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1950", + pages="1--11", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1950.txt", + key="RFC 1950", + abstract={This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="ZLIB, compressed, data, format, checksum", + doi="10.17487/RFC1950", + } + +@misc{rfc1951, + author="P. Deutsch", + title="{DEFLATE Compressed Data Format Specification version 1.3}", + howpublished="RFC 1951 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1951", + pages="1--17", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1951.txt", + key="RFC 1951", + abstract={This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="DEFLATE, compressed, data, format, coding", + doi="10.17487/RFC1951", + } + +@misc{rfc1952, + author="P. Deutsch", + title="{GZIP file format specification version 4.3}", + howpublished="RFC 1952 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1952", + pages="1--12", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1952.txt", + key="RFC 1952", + abstract={This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="GZIP, compressed, data, format, redundancy, check", + doi="10.17487/RFC1952", + } + +@misc{rfc1953, + author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall", + title="{Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0}", + howpublished="RFC 1953 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1953", + pages="1--20", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1953.txt", + key="RFC 1953", + abstract={The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IFMP, IP, flow, routing, information", + doi="10.17487/RFC1953", + } + +@misc{rfc1954, + author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall", + title="{Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0}", + howpublished="RFC 1954 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1954", + pages="1--8", + year=1996, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1954.txt", + key="RFC 1954", + abstract={This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="datagrams, IFMP", + doi="10.17487/RFC1954", + } + +@misc{rfc1955, + author="R. Hinden", + title="{New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG}", + howpublished="RFC 1955 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1955", + pages="1--5", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1955.txt", + key="RFC 1955", + abstract={This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPNG, addressing, routing", + doi="10.17487/RFC1955", + } + +@misc{rfc1956, + author="D. Engebretson and R. Plzak", + title="{Registration in the MIL Domain}", + howpublished="RFC 1956 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1956", + pages="1--2", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1956.txt", + key="RFC 1956", + abstract={This RFC describes the policy for the registration of second level domains under the ``.MIL'' domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="DoD, Department, of, Defense", + doi="10.17487/RFC1956", + } + +@misc{rfc1957, + author="R. Nelson", + title="{Some Observations on Implementations of the Post Office Protocol (POP3)}", + howpublished="RFC 1957 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1957", + pages="1--2", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1957.txt", + key="RFC 1957", + abstract={This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="client, server", + doi="10.17487/RFC1957", + } + +@misc{rfc1958, + author="B. {Carpenter (Ed.)}", + title="{Architectural Principles of the Internet}", + howpublished="RFC 1958 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1958", + pages="1--8", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3439", +url="https://www.rfc-editor.org/rfc/rfc1958.txt", + key="RFC 1958", + abstract={The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IAB", + doi="10.17487/RFC1958", + } + +@misc{rfc1959, + author="T. Howes and M. Smith", + title="{An LDAP URL Format}", + howpublished="RFC 1959 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1959", + pages="1--4", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2255", +url="https://www.rfc-editor.org/rfc/rfc1959.txt", + key="RFC 1959", + abstract={This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]}, + keywords="LDAP-URL, Lightweight, Directory, Access, Protocol, Uniform, Resource, Locator", + doi="10.17487/RFC1959", + } + +@misc{rfc1960, + author="T. Howes", + title="{A String Representation of LDAP Search Filters}", + howpublished="RFC 1960 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1960", + pages="1--3", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2254", +url="https://www.rfc-editor.org/rfc/rfc1960.txt", + key="RFC 1960", + abstract={The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]}, + keywords="LDAP-STR, Lightweight, Directory, Access, Protocol", + doi="10.17487/RFC1960", + } + +@misc{rfc1961, + author="P. McMahon", + title="{GSS-API Authentication Method for SOCKS Version 5}", + howpublished="RFC 1961 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1961", + pages="1--9", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1961.txt", + key="RFC 1961", + abstract={This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]}, + keywords="GSSAPI-SOC, Generic, Security, Service, Application, Program, Interface", + doi="10.17487/RFC1961", + } + +@misc{rfc1962, + author="D. Rand", + title="{The PPP Compression Control Protocol (CCP)}", + howpublished="RFC 1962 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1962", + pages="1--9", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2153", +url="https://www.rfc-editor.org/rfc/rfc1962.txt", + key="RFC 1962", + abstract={This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]}, + keywords="PPP-CCP, point-to-point, protocol, data, links", + doi="10.17487/RFC1962", + } + +@misc{rfc1963, + author="K. Schneider and S. Venters", + title="{PPP Serial Data Transport Protocol (SDTP)}", + howpublished="RFC 1963 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1963", + pages="1--20", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1963.txt", + key="RFC 1963", + abstract={This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Point-to-Point, Protocol", + doi="10.17487/RFC1963", + } + +@misc{rfc1964, + author="J. Linn", + title="{The Kerberos Version 5 GSS-API Mechanism}", + howpublished="RFC 1964 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1964", + pages="1--20", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4121, 6649", +url="https://www.rfc-editor.org/rfc/rfc1964.txt", + key="RFC 1964", + abstract={This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS-TRACK]}, + keywords="GSSAPI-KER, Generic, Security, Service, Application, Program, Interface", + doi="10.17487/RFC1964", + } + +@misc{rfc1965, + author="P. Traina", + title="{Autonomous System Confederations for BGP}", + howpublished="RFC 1965 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1965", + pages="1--7", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3065", +url="https://www.rfc-editor.org/rfc/rfc1965.txt", + key="RFC 1965", + abstract={This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. This memo defines an Experimental Protocol for the Internet community.}, + keywords="BGP-ASC, Border, Gateway, Protocol", + doi="10.17487/RFC1965", + } + +@misc{rfc1966, + author="T. Bates and R. Chandra", + title="{BGP Route Reflection An alternative to full mesh IBGP}", + howpublished="RFC 1966 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1966", + pages="1--7", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4456, updated by RFC 2796", +url="https://www.rfc-editor.org/rfc/rfc1966.txt", + key="RFC 1966", + abstract={This document describes the use and design of a method known as ``Route Reflection'' to alleviate the the need for ``full mesh'' IBGP. This memo defines an Experimental Protocol for the Internet community.}, + keywords="BGP-RR, Border, Gateway, Protocol, autonomous, system", + doi="10.17487/RFC1966", + } + +@misc{rfc1967, + author="K. Schneider and R. Friend", + title="{PPP LZS-DCP Compression Protocol (LZS-DCP)}", + howpublished="RFC 1967 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1967", + pages="1--18", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1967.txt", + key="RFC 1967", + abstract={This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Point-to-Point, Protocol, Compression, Control, CCP", + doi="10.17487/RFC1967", + } + +@misc{rfc1968, + author="G. Meyer", + title="{The PPP Encryption Control Protocol (ECP)}", + howpublished="RFC 1968 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1968", + pages="1--11", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1968.txt", + key="RFC 1968", + abstract={This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK]}, + keywords="PPP-ECP, Point-to-Point, Protocol, data", + doi="10.17487/RFC1968", + } + +@misc{rfc1969, + author="K. Sklower and G. Meyer", + title="{The PPP DES Encryption Protocol (DESE)}", + howpublished="RFC 1969 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1969", + pages="1--10", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2419", +url="https://www.rfc-editor.org/rfc/rfc1969.txt", + key="RFC 1969", + abstract={This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Point-to-Point, Protocol, encapsulated, packets", + doi="10.17487/RFC1969", + } + +@misc{rfc1970, + author="T. Narten and E. Nordmark and W. Simpson", + title="{Neighbor Discovery for IP Version 6 (IPv6)}", + howpublished="RFC 1970 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1970", + pages="1--82", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2461", +url="https://www.rfc-editor.org/rfc/rfc1970.txt", + key="RFC 1970", + abstract={This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]}, + keywords="Internet, Protocol", + doi="10.17487/RFC1970", + } + +@misc{rfc1971, + author="S. Thomson and T. Narten", + title="{IPv6 Stateless Address Autoconfiguration}", + howpublished="RFC 1971 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1971", + pages="1--23", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2462", +url="https://www.rfc-editor.org/rfc/rfc1971.txt", + key="RFC 1971", + abstract={This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]}, + keywords="Internet, Protocol, link-local, address, Duplicate, Address, Detection, procedure", + doi="10.17487/RFC1971", + } + +@misc{rfc1972, + author="M. Crawford", + title="{A Method for the Transmission of IPv6 Packets over Ethernet Networks}", + howpublished="RFC 1972 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1972", + pages="1--4", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2464", +url="https://www.rfc-editor.org/rfc/rfc1972.txt", + key="RFC 1972", + abstract={This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]}, + keywords="IPV6-ETHER, Internet, Protocol, frame, format, transmission", + doi="10.17487/RFC1972", + } + +@misc{rfc1973, + author="W. Simpson", + title="{PPP in Frame Relay}", + howpublished="RFC 1973 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1973", + pages="1--10", + year=1996, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1973.txt", + key="RFC 1973", + abstract={This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="PPP-FRAME, Point-to-Point, Protocol, encapsulated, packets", + doi="10.17487/RFC1973", + } + +@misc{rfc1974, + author="R. Friend and W. Simpson", + title="{PPP Stac LZS Compression Protocol}", + howpublished="RFC 1974 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1974", + pages="1--20", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1974.txt", + key="RFC 1974", + abstract={This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP-STAC, Point-to-Point, Protocol, Compression, Control, CCP", + doi="10.17487/RFC1974", + } + +@misc{rfc1975, + author="D. Schremp and J. Black and J. Weiss", + title="{PPP Magnalink Variable Resource Compression}", + howpublished="RFC 1975 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1975", + pages="1--6", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1975.txt", + key="RFC 1975", + abstract={The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP-MAG, Point-to-Point, Protocol, MVRCA", + doi="10.17487/RFC1975", + } + +@misc{rfc1976, + author="K. Schneider and S. Venters", + title="{PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)}", + howpublished="RFC 1976 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1976", + pages="1--10", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1976.txt", + key="RFC 1976", + abstract={This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP-DCE, Point-to-Point, Protocol, LCP, extension", + doi="10.17487/RFC1976", + } + +@misc{rfc1977, + author="V. Schryver", + title="{PPP BSD Compression Protocol}", + howpublished="RFC 1977 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1977", + pages="1--25", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1977.txt", + key="RFC 1977", + abstract={This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP-BSD, Point-to-Point, Protocol, Unix, Compress", + doi="10.17487/RFC1977", + } + +@misc{rfc1978, + author="D. Rand", + title="{PPP Predictor Compression Protocol}", + howpublished="RFC 1978 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1978", + pages="1--9", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1978.txt", + key="RFC 1978", + abstract={This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP-PRED, Point-to-Point, Protocol", + doi="10.17487/RFC1978", + } + +@misc{rfc1979, + author="J. Woods", + title="{PPP Deflate Protocol}", + howpublished="RFC 1979 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1979", + pages="1--10", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1979.txt", + key="RFC 1979", + abstract={This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PPP-DEFL, Point-to-Point, Protocol, Compression, Control", + doi="10.17487/RFC1979", + } + +@misc{rfc1980, + author="J. Seidman", + title="{A Proposed Extension to HTML : Client-Side Image Maps}", + howpublished="RFC 1980 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="1980", + pages="1--7", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2854", +url="https://www.rfc-editor.org/rfc/rfc1980.txt", + key="RFC 1980", + abstract={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.}, + keywords="HyperText, Markup, Language, Uniform, Identifier, URI", + doi="10.17487/RFC1980", + } + +@misc{rfc1981, + author="J. McCann and S. Deering and J. Mogul", + title="{Path MTU Discovery for IP version 6}", + howpublished="RFC 1981 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1981", + pages="1--15", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8201", +url="https://www.rfc-editor.org/rfc/rfc1981.txt", + key="RFC 1981", + abstract={This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. [STANDARDS-TRACK]}, + keywords="MTU-IPV6, Internet, Protocol", + doi="10.17487/RFC1981", + } + +@misc{rfc1982, + author="R. Elz and R. Bush", + title="{Serial Number Arithmetic}", + howpublished="RFC 1982 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1982", + pages="1--6", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1982.txt", + key="RFC 1982", + abstract={The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]}, + keywords="SNA, domain, name, system, DNS", + doi="10.17487/RFC1982", + } + +@misc{rfc1983, + author="G. {Malkin (Ed.)}", + title="{Internet Users' Glossary}", + howpublished="RFC 1983 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1983", + pages="1--62", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1983.txt", + key="RFC 1983", + abstract={There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="basic, terms, acronyms", + doi="10.17487/RFC1983", + } + +@misc{rfc1984, + author="IAB and IESG", + title="{IAB and IESG Statement on Cryptographic Technology and the Internet}", + howpublished="RFC 1984 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="1984", + pages="1--5", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1984.txt", + key="RFC 1984", + abstract={The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="security, privacy", + doi="10.17487/RFC1984", + } + +@misc{rfc1985, + author="J. De Winter", + title="{SMTP Service Extension for Remote Message Queue Starting}", + howpublished="RFC 1985 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1985", + pages="1--7", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1985.txt", + key="RFC 1985", + abstract={This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK]}, + keywords="SMTP-ETRN, Simple, ETRN, Mail, Transfer, Protocol", + doi="10.17487/RFC1985", + } + +@misc{rfc1986, + author="W. Polites and W. Wollman and D. Woo and R. Langan", + title="{Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)}", + howpublished="RFC 1986 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="1986", + pages="1--21", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1986.txt", + key="RFC 1986", + abstract={This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.}, + keywords="ETFTP, TFTP, NETBLT", + doi="10.17487/RFC1986", + } + +@misc{rfc1987, + author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall", + title="{Ipsilon's General Switch Management Protocol Specification Version 1.1}", + howpublished="RFC 1987 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1987", + pages="1--44", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2297", +url="https://www.rfc-editor.org/rfc/rfc1987.txt", + key="RFC 1987", + abstract={The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="GSMP, ATM, switch", + doi="10.17487/RFC1987", + } + +@misc{rfc1988, + author="G. McAnally and D. Gilbert and J. Flick", + title="{Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework}", + howpublished="RFC 1988 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1988", + pages="1--2", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1988.txt", + key="RFC 1988", + abstract={This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="HP", + doi="10.17487/RFC1988", + } + +@misc{rfc1989, + author="W. Simpson", + title="{PPP Link Quality Monitoring}", + howpublished="RFC 1989 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1989", + pages="1--16", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1989.txt", + key="RFC 1989", + abstract={This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK]}, + keywords="PPP-LINK, Point-to-Point, Protocol", + doi="10.17487/RFC1989", + } + +@misc{rfc1990, + author="K. Sklower and B. Lloyd and G. McGregor and D. Carr and T. Coradetti", + title="{The PPP Multilink Protocol (MP)}", + howpublished="RFC 1990 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1990", + pages="1--24", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1990.txt", + key="RFC 1990", + abstract={This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]}, + keywords="PPP-MP, Point-to-Point, Protocol, datagrams", + doi="10.17487/RFC1990", + } + +@misc{rfc1991, + author="D. Atkins and W. Stallings and P. Zimmermann", + title="{PGP Message Exchange Formats}", + howpublished="RFC 1991 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1991", + pages="1--21", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4880", +url="https://www.rfc-editor.org/rfc/rfc1991.txt", + key="RFC 1991", + abstract={This document describes the format of ``PGP files'', i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PGP-MEF, Pretty, Good, Privacy, encryption, electronic, mail", + doi="10.17487/RFC1991", + } + +@misc{rfc1992, + author="I. Castineyra and N. Chiappa and M. Steenstrup", + title="{The Nimrod Routing Architecture}", + howpublished="RFC 1992 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1992", + pages="1--27", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1992.txt", + key="RFC 1992", + abstract={Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork. First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF. In this document, we present a detailed description of this architecture. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="scalable, internetwork", + doi="10.17487/RFC1992", + } + +@misc{rfc1993, + author="A. Barbir and D. Carr and W. Simpson", + title="{PPP Gandalf FZA Compression Protocol}", + howpublished="RFC 1993 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1993", + pages="1--7", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1993.txt", + key="RFC 1993", + abstract={This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard.}, + keywords="Point-to-Point, Protocol", + doi="10.17487/RFC1993", + } + +@misc{rfc1994, + author="W. Simpson", + title="{PPP Challenge Handshake Authentication Protocol (CHAP)}", + howpublished="RFC 1994 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="1994", + pages="1--13", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2484", +url="https://www.rfc-editor.org/rfc/rfc1994.txt", + key="RFC 1994", + abstract={This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. [STANDARDS-TRACK]}, + keywords="PPP-CHAP, Point-to-Point, Protocol, cryptology", + doi="10.17487/RFC1994", + } + +@misc{rfc1995, + author="M. Ohta", + title="{Incremental Zone Transfer in DNS}", + howpublished="RFC 1995 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1995", + pages="1--8", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1995.txt", + key="RFC 1995", + abstract={This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]}, + keywords="DNS-IZT, Domain, Name, System, IXFR", + doi="10.17487/RFC1995", + } + +@misc{rfc1996, + author="P. Vixie", + title="{A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)}", + howpublished="RFC 1996 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1996", + pages="1--7", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1996.txt", + key="RFC 1996", + abstract={This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]}, + keywords="DNS-NOTIFY, Domain, Name, System", + doi="10.17487/RFC1996", + } + +@misc{rfc1997, + author="R. Chandra and P. Traina and T. Li", + title="{BGP Communities Attribute}", + howpublished="RFC 1997 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="1997", + pages="1--5", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7606", +url="https://www.rfc-editor.org/rfc/rfc1997.txt", + key="RFC 1997", + abstract={This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]}, + keywords="BGP-COMM, Border, Gateway, Protocol", + doi="10.17487/RFC1997", + } + +@misc{rfc1998, + author="E. Chen and T. Bates", + title="{An Application of the BGP Community Attribute in Multi-home Routing}", + howpublished="RFC 1998 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1998", + pages="1--9", + year=1996, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1998.txt", + key="RFC 1998", + abstract={This document presents an application of the BGP community attribute [2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Border, Gateway, Protocol", + doi="10.17487/RFC1998", + } + +@misc{rfc1999, + author="J. Elliott", + title="{Request for Comments Summary RFC Numbers 1900-1999}", + howpublished="RFC 1999 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="1999", + pages="1--20", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc1999.txt", + key="RFC 1999", + keywords="Index", + doi="10.17487/RFC1999", + } + +@misc{rfc2000, + author="J. {Postel (Ed.)}", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2000 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2000", + pages="1--56", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2200", +url="https://www.rfc-editor.org/rfc/rfc2000.txt", + key="RFC 2000", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.}, + keywords="status, procedure, index", + doi="10.17487/RFC2000", + } + +@misc{rfc2001, + author="W. Stevens", + title="{TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms}", + howpublished="RFC 2001 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2001", + pages="1--6", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2581", +url="https://www.rfc-editor.org/rfc/rfc2001.txt", + key="RFC 2001", + abstract={Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]}, + keywords="TCPSLOWSRT, Transmission, Control, Protocol", + doi="10.17487/RFC2001", + } + +@misc{rfc2002, + author="C. {Perkins (Ed.)}", + title="{IP Mobility Support}", + howpublished="RFC 2002 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2002", + pages="1--79", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3220, updated by RFC 2290", +url="https://www.rfc-editor.org/rfc/rfc2002.txt", + key="RFC 2002", + abstract={This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS-TRACK]}, + keywords="MOBILEIPSUPIP, Internet, Protocol", + doi="10.17487/RFC2002", + } + +@misc{rfc2003, + author="C. Perkins", + title="{IP Encapsulation within IP}", + howpublished="RFC 2003 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2003", + pages="1--14", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3168, 6864", +url="https://www.rfc-editor.org/rfc/rfc2003.txt", + key="RFC 2003", + abstract={This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]}, + keywords="IPENCAPIP, Internet, Protocol", + doi="10.17487/RFC2003", + } + +@misc{rfc2004, + author="C. Perkins", + title="{Minimal Encapsulation within IP}", + howpublished="RFC 2004 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2004", + pages="1--6", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2004.txt", + key="RFC 2004", + abstract={This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than ``conventional'' IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK]}, + keywords="MINI-IP, Internet, Protocol", + doi="10.17487/RFC2004", + } + +@misc{rfc2005, + author="J. Solomon", + title="{Applicability Statement for IP Mobility Support}", + howpublished="RFC 2005 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2005", + pages="1--5", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2005.txt", + key="RFC 2005", + abstract={As required by [RFC 1264], this report discusses the applicability of Mobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. [STANDARDS-TRACK]}, + keywords="Internet, Protocol", + doi="10.17487/RFC2005", + } + +@misc{rfc2006, + author="D. Cong and M. Hamlen and C. Perkins", + title="{The Definitions of Managed Objects for IP Mobility Support using SMIv2}", + howpublished="RFC 2006 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2006", + pages="1--52", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2006.txt", + key="RFC 2006", + abstract={This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK]}, + keywords="MOBILEIPMIB, Mobile, Internet, Protocol, MIB, Managed, Information, Base", + doi="10.17487/RFC2006", + } + +@misc{rfc2007, + author="J. Foster and M. Isaacs and M. Prior", + title="{Catalogue of Network Training Materials}", + howpublished="RFC 2007 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2007", + pages="1--55", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2007.txt", + key="RFC 2007", + abstract={The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="TRAINMAT, IETF, TERENA", + doi="10.17487/RFC2007", + } + +@misc{rfc2008, + author="Y. Rekhter and T. Li", + title="{Implications of Various Address Allocation Policies for Internet Routing}", + howpublished="RFC 2008 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2008", + pages="1--13", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2008.txt", + key="RFC 2008", + abstract={The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="IP, unicast", + doi="10.17487/RFC2008", + } + +@misc{rfc2009, + author="T. Imielinski and J. Navas", + title="{GPS-Based Addressing and Routing}", + howpublished="RFC 2009 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2009", + pages="1--27", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2009.txt", + key="RFC 2009", + abstract={This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community.}, + keywords="GPS-AR, domain, names, geographic", + doi="10.17487/RFC2009", + } + +@misc{rfc2010, + author="B. Manning and P. Vixie", + title="{Operational Criteria for Root Name Servers}", + howpublished="RFC 2010 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2010", + pages="1--7", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2870", +url="https://www.rfc-editor.org/rfc/rfc2010.txt", + key="RFC 2010", + abstract={This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="host, hardware", + doi="10.17487/RFC2010", + } + +@misc{rfc2011, + author="K. {McCloghrie (Ed.)}", + title="{SNMPv2 Management Information Base for the Internet Protocol using SMIv2}", + howpublished="RFC 2011 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2011", + pages="1--18", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4293", +url="https://www.rfc-editor.org/rfc/rfc2011.txt", + key="RFC 2011", + abstract={This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]}, + keywords="MIB-IP, IP, Simple, Network, Management, Protocol, MIB", + doi="10.17487/RFC2011", + } + +@misc{rfc2012, + author="K. {McCloghrie (Ed.)}", + title="{SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2}", + howpublished="RFC 2012 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2012", + pages="1--10", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4022", +url="https://www.rfc-editor.org/rfc/rfc2012.txt", + key="RFC 2012", + abstract={This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]}, + keywords="MIB-TCP, TCP, Simple, Network, Management, Protocol, MIB", + doi="10.17487/RFC2012", + } + +@misc{rfc2013, + author="K. {McCloghrie (Ed.)}", + title="{SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2}", + howpublished="RFC 2013 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2013", + pages="1--6", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4113", +url="https://www.rfc-editor.org/rfc/rfc2013.txt", + key="RFC 2013", + abstract={This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]}, + keywords="MIB-UDP], Simple, Network, Management, Protocol, MIB, UDP", + doi="10.17487/RFC2013", + } + +@misc{rfc2014, + author="A. Weinrib and J. Postel", + title="{IRTF Research Group Guidelines and Procedures}", + howpublished="RFC 2014 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2014", + pages="1--13", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2014.txt", + key="RFC 2014", + abstract={This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet, Research, Task, Force", + doi="10.17487/RFC2014", + } + +@misc{rfc2015, + author="M. Elkins", + title="{MIME Security with Pretty Good Privacy (PGP)}", + howpublished="RFC 2015 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2015", + pages="1--8", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3156", +url="https://www.rfc-editor.org/rfc/rfc2015.txt", + key="RFC 2015", + abstract={This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK]}, + keywords="MIME-PGP, Authentication, Encryption", + doi="10.17487/RFC2015", + } + +@misc{rfc2016, + author="L. Daigle and P. Deutsch and B. Heelan and C. Alpaugh and M. Maclachlan", + title="{Uniform Resource Agents (URAs)}", + howpublished="RFC 2016 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2016", + pages="1--21", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2016.txt", + key="RFC 2016", + abstract={This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. This memo defines an Experimental Protocol for the Internet community.}, + keywords="URAS", + doi="10.17487/RFC2016", + } + +@misc{rfc2017, + author="N. Freed and K. Moore and A. Cargille", + title="{Definition of the URL MIME External-Body Access-Type}", + howpublished="RFC 2017 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2017", + pages="1--5", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2017.txt", + key="RFC 2017", + abstract={This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]}, + keywords="URL-ACC, Uniform, Resource, Locators, Multipurpose, Internet, Message, Extensions", + doi="10.17487/RFC2017", + } + +@misc{rfc2018, + author="M. Mathis and J. Mahdavi and S. Floyd and A. Romanow", + title="{TCP Selective Acknowledgment Options}", + howpublished="RFC 2018 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2018", + pages="1--12", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2018.txt", + key="RFC 2018", + abstract={This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]}, + keywords="TCP-ACK, Transmission, Control, Protocol, SACK", + doi="10.17487/RFC2018", + } + +@misc{rfc2019, + author="M. Crawford", + title="{Transmission of IPv6 Packets Over FDDI}", + howpublished="RFC 2019 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2019", + pages="1--6", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2467", +url="https://www.rfc-editor.org/rfc/rfc2019.txt", + key="RFC 2019", + abstract={This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]}, + keywords="IPV6-FDDI, frame, format, Fiber, Distributed, Data, Interface", + doi="10.17487/RFC2019", + } + +@misc{rfc2020, + author="J. Flick", + title="{IEEE 802.12 Interface MIB}", + howpublished="RFC 2020 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2020", + pages="1--31", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2020.txt", + key="RFC 2020", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK]}, + keywords="802.12-MIB, Management, Information, Base", + doi="10.17487/RFC2020", + } + +@misc{rfc2021, + author="S. Waldbusser", + title="{Remote Network Monitoring Management Information Base Version 2 using SMIv2}", + howpublished="RFC 2021 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2021", + pages="1--130", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4502", +url="https://www.rfc-editor.org/rfc/rfc2021.txt", + key="RFC 2021", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]}, + keywords="RMON-MIB, RMON, MIB", + doi="10.17487/RFC2021", + } + +@misc{rfc2022, + author="G. Armitage", + title="{Support for Multicast over UNI 3.0/3.1 based ATM Networks}", + howpublished="RFC 2022 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2022", + pages="1--82", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2022.txt", + key="RFC 2022", + abstract={This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. [STANDARDS-TRACK]}, + keywords="MULTI-UNI, Asynchronous, Transfer, Mode", + doi="10.17487/RFC2022", + } + +@misc{rfc2023, + author="D. Haskin and E. Allen", + title="{IP Version 6 over PPP}", + howpublished="RFC 2023 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2023", + pages="1--10", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2472", +url="https://www.rfc-editor.org/rfc/rfc2023.txt", + key="RFC 2023", + abstract={This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. [STANDARDS-TRACK]}, + keywords="IPV6-PPP, Internet, Protocol, Point, IPv6", + doi="10.17487/RFC2023", + } + +@misc{rfc2024, + author="D. {Chen (Ed.)} and P. Gayek and S. Nix", + title="{Definitions of Managed Objects for Data Link Switching using SMIv2}", + howpublished="RFC 2024 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2024", + pages="1--90", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2024.txt", + key="RFC 2024", + abstract={This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw). [STANDARDS-TRACK]}, + keywords="DLSW-MIB, MIB, DLSW, Management, Information, Base", + doi="10.17487/RFC2024", + } + +@misc{rfc2025, + author="C. Adams", + title="{The Simple Public-Key GSS-API Mechanism (SPKM)}", + howpublished="RFC 2025 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2025", + pages="1--45", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2025.txt", + key="RFC 2025", + abstract={This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. [STANDARDS-TRACK]}, + keywords="SPKM", + doi="10.17487/RFC2025", + } + +@misc{rfc2026, + author="S. Bradner", + title="{The Internet Standards Process -- Revision 3}", + howpublished="RFC 2026 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2026", + pages="1--36", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3667, 3668, 3932, 3978, 3979, 5378, 5657, 5742, 6410, 7100, 7127, 7475, 8179", +url="https://www.rfc-editor.org/rfc/rfc2026.txt", + key="RFC 2026", + abstract={This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Protocols, copyrights, intellectual, property", + doi="10.17487/RFC2026", + } + +@misc{rfc2027, + author="J. Galvin", + title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}", + howpublished="RFC 2027 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2027", + pages="1--11", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2282", +url="https://www.rfc-editor.org/rfc/rfc2027.txt", + key="RFC 2027", + abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet, Architecture, Board, Engineering, Steering, Group", + doi="10.17487/RFC2027", + } + +@misc{rfc2028, + author="R. Hovey and S. Bradner", + title="{The Organizations Involved in the IETF Standards Process}", + howpublished="RFC 2028 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2028", + pages="1--7", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3668, 3979", +url="https://www.rfc-editor.org/rfc/rfc2028.txt", + key="RFC 2028", + abstract={This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet, Engineering, Task, Force", + doi="10.17487/RFC2028", + } + +@misc{rfc2029, + author="M. Speer and D. Hoffman", + title="{RTP Payload Format of Sun's CellB Video Encoding}", + howpublished="RFC 2029 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2029", + pages="1--6", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2029.txt", + key="RFC 2029", + abstract={This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK]}, + keywords="RTP-CELLB, Real, Time, Transport, Protocol", + doi="10.17487/RFC2029", + } + +@misc{rfc2030, + author="D. Mills", + title="{Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI}", + howpublished="RFC 2030 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2030", + pages="1--18", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4330", +url="https://www.rfc-editor.org/rfc/rfc2030.txt", + key="RFC 2030", + abstract={This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="NTP, SNTP, time, computer, clock, synchronization", + doi="10.17487/RFC2030", + } + +@misc{rfc2031, + author="E. Huizer", + title="{IETF-ISOC relationship}", + howpublished="RFC 2031 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2031", + pages="1--4", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2031.txt", + key="RFC 2031", + abstract={This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Society, Engineering, Task, Force", + doi="10.17487/RFC2031", + } + +@misc{rfc2032, + author="T. Turletti and C. Huitema", + title="{RTP Payload Format for H.261 Video Streams}", + howpublished="RFC 2032 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2032", + pages="1--11", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4587", +url="https://www.rfc-editor.org/rfc/rfc2032.txt", + key="RFC 2032", + abstract={This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]}, + keywords="RTP-H.261, Real, Time, Transport, Protocol", + doi="10.17487/RFC2032", + } + +@misc{rfc2033, + author="J. Myers", + title="{Local Mail Transfer Protocol}", + howpublished="RFC 2033 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2033", + pages="1--7", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2033.txt", + key="RFC 2033", + abstract={SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="LMTP, SMTP, Simple, Mail, Transfer, Protocol", + doi="10.17487/RFC2033", + } + +@misc{rfc2034, + author="N. Freed", + title="{SMTP Service Extension for Returning Enhanced Error Codes}", + howpublished="RFC 2034 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2034", + pages="1--6", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2034.txt", + key="RFC 2034", + abstract={This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]}, + keywords="SMTP-ENH, Simple, Mail, Transfer, Protocol", + doi="10.17487/RFC2034", + } + +@misc{rfc2035, + author="L. Berc and W. Fenner and R. Frederick and S. McCanne", + title="{RTP Payload Format for JPEG-compressed Video}", + howpublished="RFC 2035 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2035", + pages="1--16", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2435", +url="https://www.rfc-editor.org/rfc/rfc2035.txt", + key="RFC 2035", + abstract={This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. [STANDARDS-TRACK]}, + keywords="RTP-JPEG, Real, Time, Transport, Protocol, Joint, Photographic, Experts, Group", + doi="10.17487/RFC2035", + } + +@misc{rfc2036, + author="G. Huston", + title="{Observations on the use of Components of the Class A Address Space within the Internet}", + howpublished="RFC 2036 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2036", + pages="1--9", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2036.txt", + key="RFC 2036", + abstract={This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of the Class A address space to registries, for deployment within the Internet as class-less address blocks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Assigned, Numbers, Authority, IANA", + doi="10.17487/RFC2036", + } + +@misc{rfc2037, + author="K. McCloghrie and A. Bierman", + title="{Entity MIB using SMIv2}", + howpublished="RFC 2037 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2037", + pages="1--35", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2737", +url="https://www.rfc-editor.org/rfc/rfc2037.txt", + key="RFC 2037", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]}, + keywords="ENTITY-MIB, Management, Information, Base, SNMP", + doi="10.17487/RFC2037", + } + +@misc{rfc2038, + author="D. Hoffman and G. Fernando and V. Goyal", + title="{RTP Payload Format for MPEG1/MPEG2 Video}", + howpublished="RFC 2038 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2038", + pages="1--11", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2250", +url="https://www.rfc-editor.org/rfc/rfc2038.txt", + key="RFC 2038", + abstract={This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. [STANDARDS-TRACK]}, + keywords="Real, Time, Transport, Protocol", + doi="10.17487/RFC2038", + } + +@misc{rfc2039, + author="C. Kalbfleisch", + title="{Applicability of Standards Track MIBs to Management of World Wide Web Servers}", + howpublished="RFC 2039 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2039", + pages="1--14", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2039.txt", + key="RFC 2039", + abstract={This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Management, Information, Base, HTTP", + doi="10.17487/RFC2039", + } + +@misc{rfc2040, + author="R. Baldwin and R. Rivest", + title="{The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms}", + howpublished="RFC 2040 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2040", + pages="1--29", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2040.txt", + key="RFC 2040", + abstract={This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RC5, Cipher, Block, Chaining, CBC", + doi="10.17487/RFC2040", + } + +@misc{rfc2041, + author="B. Noble and G. Nguyen and M. Satyanarayanan and R. Katz", + title="{Mobile Network Tracing}", + howpublished="RFC 2041 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2041", + pages="1--27", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2041.txt", + key="RFC 2041", + abstract={This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, Internet, Protocol", + doi="10.17487/RFC2041", + } + +@misc{rfc2042, + author="B. Manning", + title="{Registering New BGP Attribute Types}", + howpublished="RFC 2042 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2042", + pages="1--3", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2042.txt", + key="RFC 2042", + abstract={This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Border, Gateway, Protocol", + doi="10.17487/RFC2042", + } + +@misc{rfc2043, + author="A. Fuqua", + title="{The PPP SNA Control Protocol (SNACP)}", + howpublished="RFC 2043 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2043", + pages="1--7", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2043.txt", + key="RFC 2043", + abstract={This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. [STANDARDS-TRACK]}, + keywords="PPP-SNACP, Point-to-point, protocol, systems, network, architecture", + doi="10.17487/RFC2043", + } + +@misc{rfc2044, + author="F. Yergeau", + title="{UTF-8, a transformation format of Unicode and ISO 10646}", + howpublished="RFC 2044 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2044", + pages="1--6", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2279", +url="https://www.rfc-editor.org/rfc/rfc2044.txt", + key="RFC 2044", + abstract={The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="UCS, Transformation, Format", + doi="10.17487/RFC2044", + } + +@misc{rfc2045, + author="N. Freed and N. Borenstein", + title="{Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies}", + howpublished="RFC 2045 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2045", + pages="1--31", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2184, 2231, 5335, 6532", +url="https://www.rfc-editor.org/rfc/rfc2045.txt", + key="RFC 2045", + abstract={This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]}, + keywords="MIME, media, types, headers", + doi="10.17487/RFC2045", + } + +@misc{rfc2046, + author="N. Freed and N. Borenstein", + title="{Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types}", + howpublished="RFC 2046 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2046", + pages="1--44", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2646, 3798, 5147, 6657, 8098", +url="https://www.rfc-editor.org/rfc/rfc2046.txt", + key="RFC 2046", + abstract={This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]}, + keywords="MIME-MEDIA, headers, structure", + doi="10.17487/RFC2046", + } + +@misc{rfc2047, + author="K. Moore", + title="{MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text}", + howpublished="RFC 2047 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2047", + pages="1--15", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2184, 2231", +url="https://www.rfc-editor.org/rfc/rfc2047.txt", + key="RFC 2047", + abstract={This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK]}, + keywords="MIME-MSG, media, type", + doi="10.17487/RFC2047", + } + +@misc{rfc2048, + author="N. Freed and J. Klensin and J. Postel", + title="{Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures}", + howpublished="RFC 2048 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2048", + pages="1--21", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4288, 4289, updated by RFC 3023", +url="https://www.rfc-editor.org/rfc/rfc2048.txt", + key="RFC 2048", + abstract={This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="media, types, external, body, access, content-transfer-encodings", + doi="10.17487/RFC2048", + } + +@misc{rfc2049, + author="N. Freed and N. Borenstein", + title="{Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples}", + howpublished="RFC 2049 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2049", + pages="1--24", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2049.txt", + key="RFC 2049", + abstract={This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK]}, + keywords="MIME-CONF, media, type, message, formats", + doi="10.17487/RFC2049", + } + +@misc{rfc2050, + author="K. Hubbard and M. Kosters and D. Conrad and D. Karrenberg and J. Postel", + title="{Internet Registry IP Allocation Guidelines}", + howpublished="RFC 2050 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2050", + pages="1--13", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7020", +url="https://www.rfc-editor.org/rfc/rfc2050.txt", + key="RFC 2050", + abstract={This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet, Addresses, Network, Numbers", + doi="10.17487/RFC2050", + } + +@misc{rfc2051, + author="M. Allen and B. Clouston and Z. Kielczewski and W. Kwan and B. Moore", + title="{Definitions of Managed Objects for APPC using SMIv2}", + howpublished="RFC 2051 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2051", + pages="1--124", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2051.txt", + key="RFC 2051", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]}, + keywords="SNANAU-APP", + doi="10.17487/RFC2051", + } + +@misc{rfc2052, + author="A. Gulbrandsen and P. Vixie", + title="{A DNS RR for specifying the location of services (DNS SRV)}", + howpublished="RFC 2052 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2052", + pages="1--10", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2782", +url="https://www.rfc-editor.org/rfc/rfc2052.txt", + key="RFC 2052", + abstract={This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). This memo defines an Experimental Protocol for the Internet community.}, + keywords="DNS-SRV, Domain, Name, System", + doi="10.17487/RFC2052", + } + +@misc{rfc2053, + author="E. Der-Danieliantz", + title="{The AM (Armenia) Domain}", + howpublished="RFC 2053 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2053", + pages="1--3", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2053.txt", + key="RFC 2053", + abstract={The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Top, Level, Domain, Country, Code", + doi="10.17487/RFC2053", + } + +@misc{rfc2054, + author="B. Callaghan", + title="{WebNFS Client Specification}", + howpublished="RFC 2054 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2054", + pages="1--16", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2054.txt", + key="RFC 2054", + abstract={This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Network, Fil, System", + doi="10.17487/RFC2054", + } + +@misc{rfc2055, + author="B. Callaghan", + title="{WebNFS Server Specification}", + howpublished="RFC 2055 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2055", + pages="1--10", + year=1996, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2055.txt", + key="RFC 2055", + abstract={This document describes the specifications for a server of WebNFS clients. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Network, Fil, System", + doi="10.17487/RFC2055", + } + +@misc{rfc2056, + author="R. Denenberg and J. Kunze and D. Lynch", + title="{Uniform Resource Locators for Z39.50}", + howpublished="RFC 2056 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2056", + pages="1--7", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2056.txt", + key="RFC 2056", + abstract={Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]}, + keywords="URLZ39.50, URL, information, retrieval", + doi="10.17487/RFC2056", + } + +@misc{rfc2057, + author="S. Bradner", + title="{Source Directed Access Control on the Internet}", + howpublished="RFC 2057 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2057", + pages="1--20", + year=1996, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2057.txt", + key="RFC 2057", + abstract={This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="content, regulation, deposition", + doi="10.17487/RFC2057", + } + +@misc{rfc2058, + author="C. Rigney and A. Rubens and W. Simpson and S. Willens", + title="{Remote Authentication Dial In User Service (RADIUS)}", + howpublished="RFC 2058 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2058", + pages="1--64", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2138", +url="https://www.rfc-editor.org/rfc/rfc2058.txt", + key="RFC 2058", + abstract={This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]}, + keywords="encryption, NAS, Network, Access, Server", + doi="10.17487/RFC2058", + } + +@misc{rfc2059, + author="C. Rigney", + title="{RADIUS Accounting}", + howpublished="RFC 2059 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2059", + pages="1--25", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2139", +url="https://www.rfc-editor.org/rfc/rfc2059.txt", + key="RFC 2059", + abstract={This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="remote, authentication, dial, in, user, service, encryption", + doi="10.17487/RFC2059", + } + +@misc{rfc2060, + author="M. Crispin", + title="{Internet Message Access Protocol - Version 4rev1}", + howpublished="RFC 2060 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2060", + pages="1--82", + year=1996, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3501", +url="https://www.rfc-editor.org/rfc/rfc2060.txt", + key="RFC 2060", + abstract={The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]}, + keywords="IMAPV4, IMAP, electronic, mail, Internet, Message, Access, Protocol", + doi="10.17487/RFC2060", + } + +@misc{rfc2061, + author="M. Crispin", + title="{IMAP4 Compatibility with IMAP2bis}", + howpublished="RFC 2061 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2061", + pages="1--3", + year=1996, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2061.txt", + key="RFC 2061", + abstract={This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IMAP, electronic, mail, Internet, Message, Access, Protocol", + doi="10.17487/RFC2061", + } + +@misc{rfc2062, + author="M. Crispin", + title="{Internet Message Access Protocol - Obsolete Syntax}", + howpublished="RFC 2062 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2062", + pages="1--8", + year=1996, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2062.txt", + key="RFC 2062", + abstract={This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IMAP, electronic, mail", + doi="10.17487/RFC2062", + } + +@misc{rfc2063, + author="N. Brownlee and C. Mills and G. Ruth", + title="{Traffic Flow Measurement: Architecture}", + howpublished="RFC 2063 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2063", + pages="1--37", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2722", +url="https://www.rfc-editor.org/rfc/rfc2063.txt", + key="RFC 2063", + abstract={This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TFM-ARCH, network, data", + doi="10.17487/RFC2063", + } + +@misc{rfc2064, + author="N. Brownlee", + title="{Traffic Flow Measurement: Meter MIB}", + howpublished="RFC 2064 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2064", + pages="1--38", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2720", +url="https://www.rfc-editor.org/rfc/rfc2064.txt", + key="RFC 2064", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. This memo defines an Experimental Protocol for the Internet community.}, + keywords="METER-MIB, Management, Information, Base, Network, Data", + doi="10.17487/RFC2064", + } + +@misc{rfc2065, + author="D. {Eastlake 3rd} and C. Kaufman", + title="{Domain Name System Security Extensions}", + howpublished="RFC 2065 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2065", + pages="1--41", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2535", +url="https://www.rfc-editor.org/rfc/rfc2065.txt", + key="RFC 2065", + abstract={The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK]}, + keywords="DNS-SEC, DNS, authentication, encryption", + doi="10.17487/RFC2065", + } + +@misc{rfc2066, + author="R. Gellens", + title="{TELNET CHARSET Option}", + howpublished="RFC 2066 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2066", + pages="1--12", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2066.txt", + key="RFC 2066", + abstract={This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TOPT-CHARSET, character, set, application", + doi="10.17487/RFC2066", + } + +@misc{rfc2067, + author="J. Renwick", + title="{IP over HIPPI}", + howpublished="RFC 2067 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2067", + pages="1--30", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2067.txt", + key="RFC 2067", + abstract={ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. This memo is a revision of RFC 1374, ``IP and ARP on HIPPI'', and is intended to replace it in the Standards Track. [STANDARDS-TRACK]}, + keywords="IP-HIPPI, ANSI, High-Performance, Parallel, Interface, Internet, Protocol", + doi="10.17487/RFC2067", + } + +@misc{rfc2068, + author="R. Fielding and J. Gettys and J. Mogul and H. Frystyk and T. Berners-Lee", + title="{Hypertext Transfer Protocol -- HTTP/1.1}", + howpublished="RFC 2068 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2068", + pages="1--162", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2616", +url="https://www.rfc-editor.org/rfc/rfc2068.txt", + key="RFC 2068", + abstract={The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]}, + keywords="HTTP-1.1, World, Wide, Web, WWW, hypermedia", + doi="10.17487/RFC2068", + } + +@misc{rfc2069, + author="J. Franks and P. Hallam-Baker and J. Hostetler and P. Leach and A. Luotonen and E. Sink and L. Stewart", + title="{An Extension to HTTP : Digest Access Authentication}", + howpublished="RFC 2069 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2069", + pages="1--18", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2617", +url="https://www.rfc-editor.org/rfc/rfc2069.txt", + key="RFC 2069", + abstract={The protocol referred to as ``HTTP/1.0'' includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as ``Digest Access Authentication''. [STANDARDS-TRACK]}, + keywords="DAA, Hypertext, Transfer, Protocol", + doi="10.17487/RFC2069", + } + +@misc{rfc2070, + author="F. Yergeau and G. Nicol and G. Adams and M. Duerst", + title="{Internationalization of the Hypertext Markup Language}", + howpublished="RFC 2070 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2070", + pages="1--43", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2854", +url="https://www.rfc-editor.org/rfc/rfc2070.txt", + key="RFC 2070", + abstract={This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. [STANDARDS-TRACK]}, + keywords="HTML-INT, HTML, WWW, World, Wide, Web", + doi="10.17487/RFC2070", + } + +@misc{rfc2071, + author="P. Ferguson and H. Berkowitz", + title="{Network Renumbering Overview: Why would I want it and what is it anyway?}", + howpublished="RFC 2071 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2071", + pages="1--14", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2071.txt", + key="RFC 2071", + abstract={This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Enterprise, Connecting, Routers", + doi="10.17487/RFC2071", + } + +@misc{rfc2072, + author="H. Berkowitz", + title="{Router Renumbering Guide}", + howpublished="RFC 2072 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2072", + pages="1--48", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4192", +url="https://www.rfc-editor.org/rfc/rfc2072.txt", + key="RFC 2072", + abstract={Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Enterprise, Connecting, Routers", + doi="10.17487/RFC2072", + } + +@misc{rfc2073, + author="Y. Rekhter and P. Lothberg and R. Hinden and S. Deering and J. Postel", + title="{An IPv6 Provider-Based Unicast Address Format}", + howpublished="RFC 2073 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2073", + pages="1--7", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2374", +url="https://www.rfc-editor.org/rfc/rfc2073.txt", + key="RFC 2073", + abstract={This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]}, + keywords="IPV6-UNI", + doi="10.17487/RFC2073", + } + +@misc{rfc2074, + author="A. Bierman and R. Iddon", + title="{Remote Network Monitoring MIB Protocol Identifiers}", + howpublished="RFC 2074 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2074", + pages="1--43", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2895", +url="https://www.rfc-editor.org/rfc/rfc2074.txt", + key="RFC 2074", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]}, + keywords="RMON-MIB, RMON, Management, Information, Base", + doi="10.17487/RFC2074", + } + +@misc{rfc2075, + author="C. Partridge", + title="{IP Echo Host Service}", + howpublished="RFC 2075 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2075", + pages="1--5", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2075.txt", + key="RFC 2075", + abstract={This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. This memo defines an Experimental Protocol for the Internet community.}, + keywords="IP-Echo, Internet, Protocol, datagram", + doi="10.17487/RFC2075", + } + +@misc{rfc2076, + author="J. Palme", + title="{Common Internet Message Headers}", + howpublished="RFC 2076 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2076", + pages="1--27", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2076.txt", + key="RFC 2076", + abstract={This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="email", + doi="10.17487/RFC2076", + } + +@misc{rfc2077, + author="S. Nelson and C. Parks and Mitra", + title="{The Model Primary Content Type for Multipurpose Internet Mail Extensions}", + howpublished="RFC 2077 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2077", + pages="1--13", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2077.txt", + key="RFC 2077", + abstract={The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as ``model''. [STANDARDS-TRACK]}, + keywords="MIME-MODEL, MIME, Media, Type, Content, Type", + doi="10.17487/RFC2077", + } + +@misc{rfc2078, + author="J. Linn", + title="{Generic Security Service Application Program Interface, Version 2}", + howpublished="RFC 2078 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2078", + pages="1--85", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2743", +url="https://www.rfc-editor.org/rfc/rfc2078.txt", + key="RFC 2078", + abstract={The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]}, + keywords="GSSAP, Authentication, Cryptology, Data, integrity", + doi="10.17487/RFC2078", + } + +@misc{rfc2079, + author="M. Smith", + title="{Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)}", + howpublished="RFC 2079 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2079", + pages="1--5", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2079.txt", + key="RFC 2079", + abstract={This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. [STANDARDS-TRACK]}, + keywords="URI-ATT, URL, Universal, Resource, Locators, Directory", + doi="10.17487/RFC2079", + } + +@misc{rfc2080, + author="G. Malkin and R. Minnear", + title="{RIPng for IPv6}", + howpublished="RFC 2080 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2080", + pages="1--19", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2080.txt", + key="RFC 2080", + abstract={This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]}, + keywords="RIPNG-IPV6, Routing, Information, Protocol, Internet", + doi="10.17487/RFC2080", + } + +@misc{rfc2081, + author="G. Malkin", + title="{RIPng Protocol Applicability Statement}", + howpublished="RFC 2081 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2081", + pages="1--4", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2081.txt", + key="RFC 2081", + abstract={As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Routing, Information, Protocol, Internet", + doi="10.17487/RFC2081", + } + +@misc{rfc2082, + author="F. Baker and R. Atkinson", + title="{RIP-2 MD5 Authentication}", + howpublished="RFC 2082 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2082", + pages="1--12", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4822", +url="https://www.rfc-editor.org/rfc/rfc2082.txt", + key="RFC 2082", + abstract={Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]}, + keywords="RIP2-MD5, Routing, Information, Protocol, Encryption", + doi="10.17487/RFC2082", + } + +@misc{rfc2083, + author="T. Boutell", + title="{PNG (Portable Network Graphics) Specification Version 1.0}", + howpublished="RFC 2083 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2083", + pages="1--102", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2083.txt", + key="RFC 2083", + abstract={This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="PNG, file, format, bitmap", + doi="10.17487/RFC2083", + } + +@misc{rfc2084, + author="G. Bossert and S. Cooper and W. Drummond", + title="{Considerations for Web Transaction Security}", + howpublished="RFC 2084 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2084", + pages="1--6", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2084.txt", + key="RFC 2084", + abstract={This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="authentication, encryption, World, Wide, Web, WWW", + doi="10.17487/RFC2084", + } + +@misc{rfc2085, + author="M. Oehler and R. Glenn", + title="{HMAC-MD5 IP Authentication with Replay Prevention}", + howpublished="RFC 2085 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2085", + pages="1--6", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2085.txt", + key="RFC 2085", + abstract={This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. [STANDARDS-TRACK]}, + keywords="HMAC-MD5, ipsec, Message, Digest, Security, Internet, Protocol, Encryption", + doi="10.17487/RFC2085", + } + +@misc{rfc2086, + author="J. Myers", + title="{IMAP4 ACL extension}", + howpublished="RFC 2086 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2086", + pages="1--8", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4314", +url="https://www.rfc-editor.org/rfc/rfc2086.txt", + key="RFC 2086", + abstract={The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]}, + keywords="IMAP4-ACL, Internet, Message, Access, Protocol, Control, List", + doi="10.17487/RFC2086", + } + +@misc{rfc2087, + author="J. Myers", + title="{IMAP4 QUOTA extension}", + howpublished="RFC 2087 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2087", + pages="1--5", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2087.txt", + key="RFC 2087", + abstract={The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]}, + keywords="IMAP4-QUO, Internet, Message, Access, Protocol", + doi="10.17487/RFC2087", + } + +@misc{rfc2088, + author="J. Myers", + title="{IMAP4 non-synchronizing literals}", + howpublished="RFC 2088 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2088", + pages="1--2", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7888, updated by RFC 4466", +url="https://www.rfc-editor.org/rfc/rfc2088.txt", + key="RFC 2088", + abstract={The Internet Message Access Protocol [STANDARDS-TRACK]}, + keywords="IMAP4-LIT, Internet, Message, Access, Protocol", + doi="10.17487/RFC2088", + } + +@misc{rfc2089, + author="B. Wijnen and D. Levi", + title="{V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent}", + howpublished="RFC 2089 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2089", + pages="1--12", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2576", +url="https://www.rfc-editor.org/rfc/rfc2089.txt", + key="RFC 2089", + abstract={The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2089", + } + +@misc{rfc2090, + author="A. Emberson", + title="{TFTP Multicast Option}", + howpublished="RFC 2090 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2090", + pages="1--6", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2090.txt", + key="RFC 2090", + abstract={This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TFTP-MULTI, Trivial, File, Transfer, Protocol", + doi="10.17487/RFC2090", + } + +@misc{rfc2091, + author="G. Meyer and S. Sherry", + title="{Triggered Extensions to RIP to Support Demand Circuits}", + howpublished="RFC 2091 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2091", + pages="1--22", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2091.txt", + key="RFC 2091", + abstract={This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]}, + keywords="RIP-TRIG", + doi="10.17487/RFC2091", + } + +@misc{rfc2092, + author="S. Sherry and G. Meyer", + title="{Protocol Analysis for Triggered RIP}", + howpublished="RFC 2092 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2092", + pages="1--6", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2092.txt", + key="RFC 2092", + abstract={As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2092", + } + +@misc{rfc2093, + author="H. Harney and C. Muckenhirn", + title="{Group Key Management Protocol (GKMP) Specification}", + howpublished="RFC 2093 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2093", + pages="1--23", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2093.txt", + key="RFC 2093", + abstract={This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.}, + keywords="GKMP-SPEC", + doi="10.17487/RFC2093", + } + +@misc{rfc2094, + author="H. Harney and C. Muckenhirn", + title="{Group Key Management Protocol (GKMP) Architecture}", + howpublished="RFC 2094 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2094", + pages="1--22", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2094.txt", + key="RFC 2094", + abstract={This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.}, + keywords="GKMP-ARCH", + doi="10.17487/RFC2094", + } + +@misc{rfc2095, + author="J. Klensin and R. Catoe and P. Krumviede", + title="{IMAP/POP AUTHorize Extension for Simple Challenge/Response}", + howpublished="RFC 2095 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2095", + pages="1--5", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2195", +url="https://www.rfc-editor.org/rfc/rfc2095.txt", + key="RFC 2095", + abstract={This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]}, + keywords="Post, Office, Protocol, Internet, Message, Access", + doi="10.17487/RFC2095", + } + +@misc{rfc2096, + author="F. Baker", + title="{IP Forwarding Table MIB}", + howpublished="RFC 2096 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2096", + pages="1--21", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4292", +url="https://www.rfc-editor.org/rfc/rfc2096.txt", + key="RFC 2096", + abstract={This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]}, + keywords="TABLE-MIB, Management, Information, Base, Internet, Protocol", + doi="10.17487/RFC2096", + } + +@misc{rfc2097, + author="G. Pall", + title="{The PPP NetBIOS Frames Control Protocol (NBFCP)}", + howpublished="RFC 2097 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2097", + pages="1--13", + year=1997, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2097.txt", + key="RFC 2097", + abstract={This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. [STANDARDS-TRACK]}, + keywords="PPP-NBFCP, Point-to-Point, Protocol", + doi="10.17487/RFC2097", + } + +@misc{rfc2098, + author="Y. Katsube and K. Nagami and H. Esaki", + title="{Toshiba's Router Architecture Extensions for ATM : Overview}", + howpublished="RFC 2098 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2098", + pages="1--18", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2098.txt", + key="RFC 2098", + abstract={This memo describes a new internetworking architecture which makes better use of the property of ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Asynchronis, Transfer, Mode, datagram, IP, Internet, Protocol", + doi="10.17487/RFC2098", + } + +@misc{rfc2099, + author="J. Elliott", + title="{Request for Comments Summary RFC Numbers 2000-2099}", + howpublished="RFC 2099 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2099", + pages="1--21", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2099.txt", + key="RFC 2099", + doi="10.17487/RFC2099", + } + +@misc{rfc2100, + author="J. Ashworth", + title="{The Naming of Hosts}", + howpublished="RFC 2100 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2100", + pages="1--3", + year=1997, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2100.txt", + key="RFC 2100", + abstract={This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="April, Fool's", + doi="10.17487/RFC2100", + } + +@misc{rfc2101, + author="B. Carpenter and J. Crowcroft and Y. Rekhter", + title="{IPv4 Address Behaviour Today}", + howpublished="RFC 2101 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2101", + pages="1--13", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2101.txt", + key="RFC 2101", + abstract={The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Protocol, Internet, Architecture, Board", + doi="10.17487/RFC2101", + } + +@misc{rfc2102, + author="R. Ramanathan", + title="{Multicast Support for Nimrod : Requirements and Solution Approaches}", + howpublished="RFC 2102 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2102", + pages="1--23", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2102.txt", + key="RFC 2102", + abstract={Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="scalable, routing, architecture", + doi="10.17487/RFC2102", + } + +@misc{rfc2103, + author="R. Ramanathan", + title="{Mobility Support for Nimrod : Challenges and Solution Approaches}", + howpublished="RFC 2103 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2103", + pages="1--17", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2103.txt", + key="RFC 2103", + abstract={We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP, Internet, Protocol, routing, addressing", + doi="10.17487/RFC2103", + } + +@misc{rfc2104, + author="H. Krawczyk and M. Bellare and R. Canetti", + title="{HMAC: Keyed-Hashing for Message Authentication}", + howpublished="RFC 2104 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2104", + pages="1--11", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6151", +url="https://www.rfc-editor.org/rfc/rfc2104.txt", + key="RFC 2104", + abstract={This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind}, + keywords="ipsec, Message, Digest, Internet, Protocol, Security, encryption", + doi="10.17487/RFC2104", + } + +@misc{rfc2105, + author="Y. Rekhter and B. Davie and D. Katz and E. Rosen and G. Swallow", + title="{Cisco Systems' Tag Switching Architecture Overview}", + howpublished="RFC 2105 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2105", + pages="1--13", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2105.txt", + key="RFC 2105", + abstract={This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="network, layer, packet, ATM, switches", + doi="10.17487/RFC2105", + } + +@misc{rfc2106, + author="S. Chiang and J. Lee and H. Yasuda", + title="{Data Link Switching Remote Access Protocol}", + howpublished="RFC 2106 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2106", + pages="1--19", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2114", +url="https://www.rfc-editor.org/rfc/rfc2106.txt", + key="RFC 2106", + abstract={This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="DLSRAP, NetBios, DLSW", + doi="10.17487/RFC2106", + } + +@misc{rfc2107, + author="K. Hamzeh", + title="{Ascend Tunnel Management Protocol - ATMP}", + howpublished="RFC 2107 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2107", + pages="1--21", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2107.txt", + key="RFC 2107", + abstract={This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RADIUS, authentication", + doi="10.17487/RFC2107", + } + +@misc{rfc2108, + author="K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie", + title="{Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2}", + howpublished="RFC 2108 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2108", + pages="1--82", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2108.txt", + key="RFC 2108", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 \&}, + keywords="802.3-MIB, MIB, Management, Information, Base", + doi="10.17487/RFC2108", + } + +@misc{rfc2109, + author="D. Kristol and L. Montulli", + title="{HTTP State Management Mechanism}", + howpublished="RFC 2109 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2109", + pages="1--21", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2965", +url="https://www.rfc-editor.org/rfc/rfc2109.txt", + key="RFC 2109", + abstract={This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]}, + keywords="HTTP-STATE, Hypertext, Transfer, Protocol, cookie", + doi="10.17487/RFC2109", + } + +@misc{rfc2110, + author="J. Palme and A. Hopmann", + title="{MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)}", + howpublished="RFC 2110 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2110", + pages="1--19", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2557", +url="https://www.rfc-editor.org/rfc/rfc2110.txt", + key="RFC 2110", + abstract={This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK]}, + keywords="MHTML, Hyper, Text, Markup, Language, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC2110", + } + +@misc{rfc2111, + author="E. Levinson", + title="{Content-ID and Message-ID Uniform Resource Locators}", + howpublished="RFC 2111 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2111", + pages="1--5", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2392", +url="https://www.rfc-editor.org/rfc/rfc2111.txt", + key="RFC 2111", + abstract={The Uniform Resource Locator (URL) schemes, ``cid:'' and ``mid:'' allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]}, + keywords="Hyper, Text, Markup, Language, URL, MIME", + doi="10.17487/RFC2111", + } + +@misc{rfc2112, + author="E. Levinson", + title="{The MIME Multipart/Related Content-type}", + howpublished="RFC 2112 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2112", + pages="1--9", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2387", +url="https://www.rfc-editor.org/rfc/rfc2112.txt", + key="RFC 2112", + abstract={The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]}, + keywords="Hyper, Text, Markup, Language, Multipurpose, Internet,Mail, Extensions", + doi="10.17487/RFC2112", + } + +@misc{rfc2113, + author="D. Katz", + title="{IP Router Alert Option}", + howpublished="RFC 2113 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2113", + pages="1--4", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5350, 6398", +url="https://www.rfc-editor.org/rfc/rfc2113.txt", + key="RFC 2113", + abstract={This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]}, + keywords="ROUT-ALERT", + doi="10.17487/RFC2113", + } + +@misc{rfc2114, + author="S. Chiang and J. Lee and H. Yasuda", + title="{Data Link Switching Client Access Protocol}", + howpublished="RFC 2114 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2114", + pages="1--22", + year=1997, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2114.txt", + key="RFC 2114", + abstract={This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="DLSCAP", + doi="10.17487/RFC2114", + } + +@misc{rfc2115, + author="C. Brown and F. Baker", + title="{Management Information Base for Frame Relay DTEs Using SMIv2}", + howpublished="RFC 2115 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2115", + pages="1--32", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2115.txt", + key="RFC 2115", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Frame Relay interfaces on DTEs. [STANDARDS-TRACK]}, + keywords="FRAME-MIB, MIB", + doi="10.17487/RFC2115", + } + +@misc{rfc2116, + author="C. Apple and K. Rossen", + title="{X.500 Implementations Catalog-96}", + howpublished="RFC 2116 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2116", + pages="1--164", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2116.txt", + key="RFC 2116", + abstract={This document is a revision to [RFC 1632]: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. [RFC 1632] is a revision of [RFC 1292]. This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Directory, Services, DSA, DUA, Agent, Interfaces", + doi="10.17487/RFC2116", + } + +@misc{rfc2117, + author="D. Estrin and D. Farinacci and A. Helmy and D. Thaler and S. Deering and M. Handley and V. Jacobson and C. Liu and P. Sharma and L. Wei", + title="{Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification}", + howpublished="RFC 2117 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2117", + pages="1--66", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2362", +url="https://www.rfc-editor.org/rfc/rfc2117.txt", + key="RFC 2117", + abstract={This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community.}, + doi="10.17487/RFC2117", + } + +@misc{rfc2118, + author="G. Pall", + title="{Microsoft Point-To-Point Compression (MPPC) Protocol}", + howpublished="RFC 2118 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2118", + pages="1--9", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2118.txt", + key="RFC 2118", + abstract={This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Point-to-Point, Protocol, PPP", + doi="10.17487/RFC2118", + } + +@misc{rfc2119, + author="S. Bradner", + title="{Key words for use in RFCs to Indicate Requirement Levels}", + howpublished="RFC 2119 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2119", + pages="1--3", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8174", +url="https://www.rfc-editor.org/rfc/rfc2119.txt", + key="RFC 2119", + abstract={In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Standards, Track, Documents", + doi="10.17487/RFC2119", + } + +@misc{rfc2120, + author="D. Chadwick", + title="{Managing the X.500 Root Naming Context}", + howpublished="RFC 2120 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2120", + pages="1--14", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2120.txt", + key="RFC 2120", + abstract={This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. This memo defines an Experimental Protocol for the Internet community.}, + keywords="X.500-NAME, ISO, International, Standards, Organization", + doi="10.17487/RFC2120", + } + +@misc{rfc2121, + author="G. Armitage", + title="{Issues affecting MARS Cluster Size}", + howpublished="RFC 2121 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2121", + pages="1--12", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2121.txt", + key="RFC 2121", + abstract={This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="ATM, Asynchronous, Transfer, Mode, Multicast, IP, Internet, Protocol", + doi="10.17487/RFC2121", + } + +@misc{rfc2122, + author="D. Mavrakis and H. Layec and K. Kartmann", + title="{VEMMI URL Specification}", + howpublished="RFC 2122 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2122", + pages="1--11", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2122.txt", + key="RFC 2122", + abstract={A new URL scheme, ``vemmi'' is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]}, + keywords="VEMMI-URL, Uniform, Resource, Locator, Enhanced, Man-Machine, Interface Videotex", + doi="10.17487/RFC2122", + } + +@misc{rfc2123, + author="N. Brownlee", + title="{Traffic Flow Measurement: Experiences with NeTraMet}", + howpublished="RFC 2123 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2123", + pages="1--34", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2123.txt", + key="RFC 2123", + abstract={This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Meter, Reader, Network", + doi="10.17487/RFC2123", + } + +@misc{rfc2124, + author="P. Amsden and J. Amweg and P. Calato and S. Bensley and G. Lyons", + title="{Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0}", + howpublished="RFC 2124 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2124", + pages="1--21", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2124.txt", + key="RFC 2124", + abstract={This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="LFAP", + doi="10.17487/RFC2124", + } + +@misc{rfc2125, + author="C. Richards and K. Smith", + title="{The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)}", + howpublished="RFC 2125 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2125", + pages="1--24", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2125.txt", + key="RFC 2125", + abstract={This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). [STANDARDS-TRACK]}, + keywords="BAP-BACP, Point-to-Point, datagram, multilink", + doi="10.17487/RFC2125", + } + +@misc{rfc2126, + author="Y. Pouffary and A. Young", + title="{ISO Transport Service on top of TCP (ITOT)}", + howpublished="RFC 2126 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2126", + pages="1--25", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2126.txt", + key="RFC 2126", + abstract={This document is a revision to STD35, RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK]}, + keywords="ITOT, International, Standards, Organization, Transmission, Control, Protocol", + doi="10.17487/RFC2126", + } + +@misc{rfc2127, + author="G. {Roeck (Ed.)}", + title="{ISDN Management Information Base using SMIv2}", + howpublished="RFC 2127 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2127", + pages="1--49", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2127.txt", + key="RFC 2127", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. [STANDARDS-TRACK]}, + keywords="ISDN-MIB, MIB, ISDN, Integrated, Services, Digital, Network", + doi="10.17487/RFC2127", + } + +@misc{rfc2128, + author="G. {Roeck (Ed.)}", + title="{Dial Control Management Information Base using SMIv2}", + howpublished="RFC 2128 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2128", + pages="1--34", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2128.txt", + key="RFC 2128", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing demand access circuits, including ISDN. [STANDARDS-TRACK]}, + keywords="DC-MIB, MIB, ISDN, Integrated, Services, Digital, Network", + doi="10.17487/RFC2128", + } + +@misc{rfc2129, + author="K. Nagami and Y. Katsube and Y. Shobatake and A. Mogi and S. Matsuzawa and T. Jinmei and H. Esaki", + title="{Toshiba's Flow Attribute Notification Protocol (FANP) Specification}", + howpublished="RFC 2129 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2129", + pages="1--19", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2129.txt", + key="RFC 2129", + abstract={This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="packet, flow, datalink, mapping", + doi="10.17487/RFC2129", + } + +@misc{rfc2130, + author="C. Weider and C. Preston and K. Simonsen and H. Alvestrand and R. Atkinson and M. Crispin and P. Svanberg", + title="{The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996}", + howpublished="RFC 2130 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2130", + pages="1--31", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6055", +url="https://www.rfc-editor.org/rfc/rfc2130.txt", + key="RFC 2130", + abstract={This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Architecture, Board, interoperability", + doi="10.17487/RFC2130", + } + +@misc{rfc2131, + author="R. Droms", + title="{Dynamic Host Configuration Protocol}", + howpublished="RFC 2131 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2131", + pages="1--45", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3396, 4361, 5494, 6842", +url="https://www.rfc-editor.org/rfc/rfc2131.txt", + key="RFC 2131", + abstract={The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]}, + keywords="DHCP, DHCPv4", + doi="10.17487/RFC2131", + } + +@misc{rfc2132, + author="S. Alexander and R. Droms", + title="{DHCP Options and BOOTP Vendor Extensions}", + howpublished="RFC 2132 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2132", + pages="1--34", + year=1997, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3442, 3942, 4361, 4833, 5494", +url="https://www.rfc-editor.org/rfc/rfc2132.txt", + key="RFC 2132", + abstract={This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]}, + keywords="DHCP-BOOTP, Dynamic, Host, Configuration, Protocol, Bootstrap", + doi="10.17487/RFC2132", + } + +@misc{rfc2133, + author="R. Gilligan and S. Thomson and J. Bound and W. Stevens", + title="{Basic Socket Interface Extensions for IPv6}", + howpublished="RFC 2133 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2133", + pages="1--32", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2553", +url="https://www.rfc-editor.org/rfc/rfc2133.txt", + key="RFC 2133", + abstract={This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="application, program, interface, API, Internet, Protocol, addresses", + doi="10.17487/RFC2133", + } + +@misc{rfc2134, + author="ISOC Board of Trustees", + title="{Articles of Incorporation of Internet Society}", + howpublished="RFC 2134 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2134", + pages="1--5", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2134.txt", + key="RFC 2134", + abstract={These are the articles of incorporation of the Internet Society. They are published for the information of the IETF community at the request of the poisson working group. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="ISOC", + doi="10.17487/RFC2134", + } + +@misc{rfc2135, + author="ISOC Board of Trustees", + title="{Internet Society By-Laws}", + howpublished="RFC 2135 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2135", + pages="1--9", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2135.txt", + key="RFC 2135", + abstract={These are the by-laws of the Internet Society, as amended, as of June 1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="ISOC", + doi="10.17487/RFC2135", + } + +@misc{rfc2136, + author="P. {Vixie (Ed.)} and S. Thomson and Y. Rekhter and J. Bound", + title="{Dynamic Updates in the Domain Name System (DNS UPDATE)}", + howpublished="RFC 2136 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2136", + pages="1--26", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3007, 4035, 4033, 4034", +url="https://www.rfc-editor.org/rfc/rfc2136.txt", + key="RFC 2136", + abstract={Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]}, + keywords="DNS-UPDATE, database, opcode, zone", + doi="10.17487/RFC2136", + } + +@misc{rfc2137, + author="D. {Eastlake 3rd}", + title="{Secure Domain Name System Dynamic Update}", + howpublished="RFC 2137 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2137", + pages="1--11", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3007", +url="https://www.rfc-editor.org/rfc/rfc2137.txt", + key="RFC 2137", + abstract={This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [STANDARDS-TRACK]}, + keywords="SDNSDU, DNS, digital, signatures, cryptographic", + doi="10.17487/RFC2137", + } + +@misc{rfc2138, + author="C. Rigney and A. Rubens and W. Simpson and S. Willens", + title="{Remote Authentication Dial In User Service (RADIUS)}", + howpublished="RFC 2138 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2138", + pages="1--65", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2865", +url="https://www.rfc-editor.org/rfc/rfc2138.txt", + key="RFC 2138", + abstract={This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]}, + keywords="RADIUS, encryption, NAS, Network, Access, Server", + doi="10.17487/RFC2138", + } + +@misc{rfc2139, + author="C. Rigney", + title="{RADIUS Accounting}", + howpublished="RFC 2139 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2139", + pages="1--25", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2866", +url="https://www.rfc-editor.org/rfc/rfc2139.txt", + key="RFC 2139", + abstract={This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RADIUS-ACC, remote, authentication, dial, in, user, service, encryption", + doi="10.17487/RFC2139", + } + +@misc{rfc2140, + author="J. Touch", + title="{TCP Control Block Interdependence}", + howpublished="RFC 2140 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2140", + pages="1--11", + year=1997, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2140.txt", + key="RFC 2140", + abstract={This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2140", + } + +@misc{rfc2141, + author="R. Moats", + title="{URN Syntax}", + howpublished="RFC 2141 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2141", + pages="1--8", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8141", +url="https://www.rfc-editor.org/rfc/rfc2141.txt", + key="RFC 2141", + abstract={Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK]}, + keywords="URN-SYNTAX, Uniform, Resource, Names", + doi="10.17487/RFC2141", + } + +@misc{rfc2142, + author="D. Crocker", + title="{Mailbox Names for Common Services, Roles and Functions}", + howpublished="RFC 2142 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2142", + pages="1--6", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2142.txt", + key="RFC 2142", + abstract={This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]}, + keywords="MAIL-SERV, email, internet, addresses", + doi="10.17487/RFC2142", + } + +@misc{rfc2143, + author="B. Elliston", + title="{Encapsulating IP with the Small Computer System Interface}", + howpublished="RFC 2143 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2143", + pages="1--5", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2143.txt", + key="RFC 2143", + abstract={This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IP-SCSI, SCSI", + doi="10.17487/RFC2143", + } + +@misc{rfc2144, + author="C. Adams", + title="{The CAST-128 Encryption Algorithm}", + howpublished="RFC 2144 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2144", + pages="1--15", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2144.txt", + key="RFC 2144", + abstract={There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="CAST-128", + doi="10.17487/RFC2144", + } + +@misc{rfc2145, + author="J. C. Mogul and R. Fielding and J. Gettys and H. Frystyk", + title="{Use and Interpretation of HTTP Version Numbers}", + howpublished="RFC 2145 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2145", + pages="1--7", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7230", +url="https://www.rfc-editor.org/rfc/rfc2145.txt", + key="RFC 2145", + abstract={HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2145", + } + +@misc{rfc2146, + author="Federal Networking Council", + title="{U.S. Government Internet Domain Names}", + howpublished="RFC 2146 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2146", + pages="1--12", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2146.txt", + key="RFC 2146", + abstract={This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain ``.GOV''. The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Gov, FED.US", + doi="10.17487/RFC2146", + } + +@misc{rfc2147, + author="D. Borman", + title="{TCP and UDP over IPv6 Jumbograms}", + howpublished="RFC 2147 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2147", + pages="1--3", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2675", +url="https://www.rfc-editor.org/rfc/rfc2147.txt", + key="RFC 2147", + abstract={IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]}, + keywords="IPv6-Jumbo, User, Datagram, Protocol, Terminal, Control, Internet", + doi="10.17487/RFC2147", + } + +@misc{rfc2148, + author="H. Alvestrand and P. Jurg", + title="{Deployment of the Internet White Pages Service}", + howpublished="RFC 2148 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2148", + pages="1--15", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2148.txt", + key="RFC 2148", + abstract={This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="X. 500, data structure, naming scheme, IWPS", + doi="10.17487/RFC2148", + } + +@misc{rfc2149, + author="R. Talpade and M. Ammar", + title="{Multicast Server Architectures for MARS-based ATM multicasting}", + howpublished="RFC 2149 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2149", + pages="1--18", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2149.txt", + key="RFC 2149", + abstract={This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2149", + } + +@misc{rfc2150, + author="J. Max and W. Stickle", + title="{Humanities and Arts: Sharing Center Stage on the Internet}", + howpublished="RFC 2150 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2150", + pages="1--62", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2150.txt", + key="RFC 2150", + abstract={The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="informational, infrastructure, guide, introduction", + doi="10.17487/RFC2150", + } + +@misc{rfc2151, + author="G. Kessler and S. Shepard", + title="{A Primer On Internet and TCP/IP Tools and Utilities}", + howpublished="RFC 2151 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2151", + pages="1--52", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2151.txt", + key="RFC 2151", + abstract={This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="resource, guide, user", + doi="10.17487/RFC2151", + } + +@misc{rfc2152, + author="D. Goldsmith and M. Davis", + title="{UTF-7 A Mail-Safe Transformation Format of Unicode}", + howpublished="RFC 2152 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2152", + pages="1--15", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2152.txt", + key="RFC 2152", + abstract={This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, ``Using Unicode with MIME''. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="UTF-7", + doi="10.17487/RFC2152", + } + +@misc{rfc2153, + author="W. Simpson", + title="{PPP Vendor Extensions}", + howpublished="RFC 2153 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2153", + pages="1--6", + year=1997, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5342, 7042", +url="https://www.rfc-editor.org/rfc/rfc2153.txt", + key="RFC 2153", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="PPP-EXT, Point-to-Point, Protocol", + doi="10.17487/RFC2153", + } + +@misc{rfc2154, + author="S. Murphy and M. Badger and B. Wellington", + title="{OSPF with Digital Signatures}", + howpublished="RFC 2154 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2154", + pages="1--29", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2154.txt", + key="RFC 2154", + abstract={This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co-existence with, standard OSPF V2 is described. This memo defines an Experimental Protocol for the Internet community.}, + keywords="OSPF-DIG", + doi="10.17487/RFC2154", + } + +@misc{rfc2155, + author="B. Clouston and B. Moore", + title="{Definitions of Managed Objects for APPN using SMIv2}", + howpublished="RFC 2155 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2155", + pages="1--124", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2455", +url="https://www.rfc-editor.org/rfc/rfc2155.txt", + key="RFC 2155", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]}, + keywords="APPN-MIB", + doi="10.17487/RFC2155", + } + +@misc{rfc2156, + author="S. Kille", + title="{MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME}", + howpublished="RFC 2156 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2156", + pages="1--144", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2156.txt", + key="RFC 2156", + abstract={This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as ``X.400'', which is a convenient shorthand. [STANDARDS-TRACK]}, + keywords="MIXER, multipurpose, internet, mail, extensions, message, transfer, protocol", + doi="10.17487/RFC2156", + } + +@misc{rfc2157, + author="H. Alvestrand", + title="{Mapping between X.400 and RFC-822/MIME Message Bodies}", + howpublished="RFC 2157 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2157", + pages="1--49", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2157.txt", + key="RFC 2157", + abstract={This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]}, + keywords="mixer, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2157", + } + +@misc{rfc2158, + author="H. Alvestrand", + title="{X.400 Image Body Parts}", + howpublished="RFC 2158 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2158", + pages="1--4", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2158.txt", + key="RFC 2158", + abstract={This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]}, + keywords="mixer, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2158", + } + +@misc{rfc2159, + author="H. Alvestrand", + title="{A MIME Body Part for FAX}", + howpublished="RFC 2159 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2159", + pages="1--7", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2159.txt", + key="RFC 2159", + abstract={This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]}, + keywords="mixer, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2159", + } + +@misc{rfc2160, + author="H. Alvestrand", + title="{Carrying PostScript in X.400 and MIME}", + howpublished="RFC 2160 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2160", + pages="1--5", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2160.txt", + key="RFC 2160", + abstract={This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]}, + keywords="mixer, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2160", + } + +@misc{rfc2161, + author="H. Alvestrand", + title="{A MIME Body Part for ODA}", + howpublished="RFC 2161 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2161", + pages="1--5", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2161.txt", + key="RFC 2161", + abstract={This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MIME-ODA, mixer, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2161", + } + +@misc{rfc2162, + author="C. Allocchio", + title="{MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail}", + howpublished="RFC 2162 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2162", + pages="1--34", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2162.txt", + key="RFC 2162", + abstract={The standard referred shortly into this document as ``X.400'' relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MAP-MAIL, mixer, multipurpose, internet, mail, extensions, mime", + doi="10.17487/RFC2162", + } + +@misc{rfc2163, + author="C. Allocchio", + title="{Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)}", + howpublished="RFC 2163 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2163", + pages="1--26", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3597", +url="https://www.rfc-editor.org/rfc/rfc2163.txt", + key="RFC 2163", + abstract={This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]}, + keywords="DNS-MCGAM, mime, internet, enhanced, Relay, Multipurpose, internet, mail, extensions, x.400, mixer", + doi="10.17487/RFC2163", + } + +@misc{rfc2164, + author="S. Kille", + title="{Use of an X.500/LDAP directory to support MIXER address mapping}", + howpublished="RFC 2164 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2164", + pages="1--10", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2164.txt", + key="RFC 2164", + abstract={This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol, mime, internet, x,.400, enhanced, relay", + doi="10.17487/RFC2164", + } + +@misc{rfc2165, + author="J. Veizades and E. Guttman and C. Perkins and S. Kaplan", + title="{Service Location Protocol}", + howpublished="RFC 2165 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2165", + pages="1--72", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2608, 2609", +url="https://www.rfc-editor.org/rfc/rfc2165.txt", + key="RFC 2165", + abstract={The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]}, + keywords="SLP", + doi="10.17487/RFC2165", + } + +@misc{rfc2166, + author="D. Bryant and P. Brittain", + title="{APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements}", + howpublished="RFC 2166 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2166", + pages="1--34", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2166.txt", + key="RFC 2166", + abstract={This document specifies a set of extensions to RFC 1795 designed to improve the scalability of DLSw clarifications to RFC 1795 in the light of the implementation experience to-date. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2166", + } + +@misc{rfc2167, + author="S. Williamson and M. Kosters and D. Blacka and J. Singh and K. Zeilstra", + title="{Referral Whois (RWhois) Protocol V1.5}", + howpublished="RFC 2167 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2167", + pages="1--69", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2167.txt", + key="RFC 2167", + abstract={This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="RWHOIS", + doi="10.17487/RFC2167", + } + +@misc{rfc2168, + author="R. Daniel and M. Mealling", + title="{Resolution of Uniform Resource Identifiers using the Domain Name System}", + howpublished="RFC 2168 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2168", + pages="1--20", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 3401, 3402, 3403, 3404, updated by RFC 2915", +url="https://www.rfc-editor.org/rfc/rfc2168.txt", + key="RFC 2168", + abstract={The requirements document for URN resolution systems defines the concept of a ``resolver discovery service''. This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.}, + doi="10.17487/RFC2168", + } + +@misc{rfc2169, + author="R. Daniel", + title="{A Trivial Convention for using HTTP in URN Resolution}", + howpublished="RFC 2169 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2169", + pages="1--9", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2169.txt", + key="RFC 2169", + abstract={This document specifies the ``THTTP'' resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="", + doi="10.17487/RFC2169", + } + +@misc{rfc2170, + author="W. Almesberger and J. Le Boudec and P. Oechslin", + title="{Application REQuested IP over ATM (AREQUIPA)}", + howpublished="RFC 2170 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2170", + pages="1--10", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2170.txt", + key="RFC 2170", + abstract={This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Protocol", + doi="10.17487/RFC2170", + } + +@misc{rfc2171, + author="K. Murakami and M. Maruyama", + title="{MAPOS - Multiple Access Protocol over SONET/SDH Version 1}", + howpublished="RFC 2171 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2171", + pages="1--9", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2171.txt", + key="RFC 2171", + abstract={This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="MAPOS-SONET", + doi="10.17487/RFC2171", + } + +@misc{rfc2172, + author="M. Maruyama and K. Murakami", + title="{MAPOS Version 1 Assigned Numbers}", + howpublished="RFC 2172 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2172", + pages="1--3", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2172.txt", + key="RFC 2172", + abstract={This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2172", + } + +@misc{rfc2173, + author="K. Murakami and M. Maruyama", + title="{A MAPOS version 1 Extension - Node Switch Protocol}", + howpublished="RFC 2173 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2173", + pages="1--6", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2173.txt", + key="RFC 2173", + abstract={This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2173", + } + +@misc{rfc2174, + author="K. Murakami and M. Maruyama", + title="{A MAPOS version 1 Extension - Switch-Switch Protocol}", + howpublished="RFC 2174 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2174", + pages="1--22", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2174.txt", + key="RFC 2174", + abstract={This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2174", + } + +@misc{rfc2175, + author="K. Murakami and M. Maruyama", + title="{MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing}", + howpublished="RFC 2175 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2175", + pages="1--6", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2175.txt", + key="RFC 2175", + abstract={This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2175", + } + +@misc{rfc2176, + author="K. Murakami and M. Maruyama", + title="{IPv4 over MAPOS Version 1}", + howpublished="RFC 2176 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2176", + pages="1--6", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc2176.txt", + key="RFC 2176", + abstract={This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="IPV4-MAPOS", + doi="10.17487/RFC2176", + } + +@misc{rfc2177, + author="B. Leiba", + title="{IMAP4 IDLE command}", + howpublished="RFC 2177 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2177", + pages="1--4", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2177.txt", + key="RFC 2177", + abstract={This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]}, + keywords="IMAP4-IDLE", + doi="10.17487/RFC2177", + } + +@misc{rfc2178, + author="J. Moy", + title="{OSPF Version 2}", + howpublished="RFC 2178 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2178", + pages="1--211", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2328", +url="https://www.rfc-editor.org/rfc/rfc2178.txt", + key="RFC 2178", + abstract={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. 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]}, + keywords="Open, Shortest, Path, First, routing, Autonomous, system, AS", + doi="10.17487/RFC2178", + } + +@misc{rfc2179, + author="A. Gwinn", + title="{Network Security For Trade Shows}", + howpublished="RFC 2179 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2179", + pages="1--10", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2179.txt", + key="RFC 2179", + abstract={This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="network, system, attacks", + doi="10.17487/RFC2179", + } + +@misc{rfc2180, + author="M. Gahrns", + title="{IMAP4 Multi-Accessed Mailbox Practice}", + howpublished="RFC 2180 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2180", + pages="1--14", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2180.txt", + key="RFC 2180", + abstract={The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Message, Access, Protocol, Client, Server", + doi="10.17487/RFC2180", + } + +@misc{rfc2181, + author="R. Elz and R. Bush", + title="{Clarifications to the DNS Specification}", + howpublished="RFC 2181 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2181", + pages="1--14", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4035, 2535, 4343, 4033, 4034, 5452", +url="https://www.rfc-editor.org/rfc/rfc2181.txt", + key="RFC 2181", + abstract={This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]}, + keywords="DNS-CLAR, Domain, Name, System", + doi="10.17487/RFC2181", + } + +@misc{rfc2182, + author="R. Elz and R. Bush and S. Bradner and M. Patton", + title="{Selection and Operation of Secondary DNS Servers}", + howpublished="RFC 2182 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2182", + pages="1--11", + year=1997, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2182.txt", + key="RFC 2182", + abstract={This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Domain, Name, System, delegated, zone", + doi="10.17487/RFC2182", + } + +@misc{rfc2183, + author="R. Troost and S. Dorner and K. {Moore (Ed.)}", + title="{Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field}", + howpublished="RFC 2183 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2183", + pages="1--12", + year=1997, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2184, 2231", +url="https://www.rfc-editor.org/rfc/rfc2183.txt", + key="RFC 2183", + abstract={This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the ``Content- Disposition'' header field, which is optional and valid for any MIME entity (``message'' or ``body part''). [STANDARDS-TRACK]}, + keywords="inline, attachment, MIME, Mail, Multimedia, EMail", + doi="10.17487/RFC2183", + } + +@misc{rfc2184, + author="N. Freed and K. Moore", + title="{MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations}", + howpublished="RFC 2184 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2184", + pages="1--9", + year=1997, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2231", +url="https://www.rfc-editor.org/rfc/rfc2184.txt", + key="RFC 2184", + abstract={This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]}, + keywords="mail, Multimedia, EMail", + doi="10.17487/RFC2184", + } + +@misc{rfc2185, + author="R. Callon and D. Haskin", + title="{Routing Aspects of IPv6 Transition}", + howpublished="RFC 2185 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2185", + pages="1--13", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2185.txt", + key="RFC 2185", + abstract={This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document ``Transition Mechanisms for IPv6 Hosts and Routers.'' Readers should be familiar with the transition mechanisms before reading this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="address, network, tunneling", + doi="10.17487/RFC2185", + } + +@misc{rfc2186, + author="D. Wessels and K. Claffy", + title="{Internet Cache Protocol (ICP), version 2}", + howpublished="RFC 2186 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2186", + pages="1--9", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2186.txt", + key="RFC 2186", + abstract={This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="ICP, www, web, http, hypertext, transfer, protocol", + doi="10.17487/RFC2186", + } + +@misc{rfc2187, + author="D. Wessels and K. Claffy", + title="{Application of Internet Cache Protocol (ICP), version 2}", + howpublished="RFC 2187 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2187", + pages="1--24", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2187.txt", + key="RFC 2187", + abstract={This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="web, www, url, uniform, resource, identifier", + doi="10.17487/RFC2187", + } + +@misc{rfc2188, + author="M. Banan and M. Taylor and J. Cheng", + title="{AT\&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2}", + howpublished="RFC 2188 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2188", + pages="1--57", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2188.txt", + key="RFC 2188", + abstract={This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="ESRO, RPC, Remote, Procedure, Call, Wireless", + doi="10.17487/RFC2188", + } + +@misc{rfc2189, + author="A. Ballardie", + title="{Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --}", + howpublished="RFC 2189 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2189", + pages="1--23", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2189.txt", + key="RFC 2189", + abstract={This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing. This memo defines an Experimental Protocol for the Internet community.}, + keywords="Inter-Domain-Protocol, IDMR", + doi="10.17487/RFC2189", + } + +@misc{rfc2190, + author="C. Zhu", + title="{RTP Payload Format for H.263 Video Streams}", + howpublished="RFC 2190 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2190", + pages="1--12", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2190.txt", + key="RFC 2190", + abstract={This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]}, + keywords="real-time, transfer", + doi="10.17487/RFC2190", + } + +@misc{rfc2191, + author="G. Armitage", + title="{VENUS - Very Extensive Non-Unicast Service}", + howpublished="RFC 2191 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2191", + pages="1--12", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2191.txt", + key="RFC 2191", + abstract={This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed ``Very Extensive NonUnicast Service'' (VENUS), and shows how complex such a service would be. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="multicast, IP, ATM", + doi="10.17487/RFC2191", + } + +@misc{rfc2192, + author="C. Newman", + title="{IMAP URL Scheme}", + howpublished="RFC 2192 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2192", + pages="1--16", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5092", +url="https://www.rfc-editor.org/rfc/rfc2192.txt", + key="RFC 2192", + abstract={This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]}, + keywords="IMAP-URL, Internet, Message, Access, Protocol, Uniform, Resource, Identifiers", + doi="10.17487/RFC2192", + } + +@misc{rfc2193, + author="M. Gahrns", + title="{IMAP4 Mailbox Referrals}", + howpublished="RFC 2193 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2193", + pages="1--9", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2193.txt", + key="RFC 2193", + abstract={Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]}, + keywords="IMAP4MAIL, Internet, Mail, Access, Protocol, messages", + doi="10.17487/RFC2193", + } + +@misc{rfc2194, + author="B. Aboba and J. Lu and J. Alsop and J. Ding and W. Wang", + title="{Review of Roaming Implementations}", + howpublished="RFC 2194 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2194", + pages="1--35", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2194.txt", + key="RFC 2194", + abstract={This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP ``confederations'' and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="ISP, Internet, Server, Provider", + doi="10.17487/RFC2194", + } + +@misc{rfc2195, + author="J. Klensin and R. Catoe and P. Krumviede", + title="{IMAP/POP AUTHorize Extension for Simple Challenge/Response}", + howpublished="RFC 2195 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2195", + pages="1--5", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2195.txt", + key="RFC 2195", + abstract={This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]}, + keywords="IMAPPOPAU, Post, Office, Protocol, Internet, Message, Access", + doi="10.17487/RFC2195", + } + +@misc{rfc2196, + author="B. Fraser", + title="{Site Security Handbook}", + howpublished="RFC 2196 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2196", + pages="1--75", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2196.txt", + key="RFC 2196", + abstract={This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2196", + } + +@misc{rfc2197, + author="N. Freed", + title="{SMTP Service Extension for Command Pipelining}", + howpublished="RFC 2197 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2197", + pages="1--8", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2920", +url="https://www.rfc-editor.org/rfc/rfc2197.txt", + key="RFC 2197", + abstract={This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]}, + keywords="SMTP-Pipe, simple, mail, transfer, TCP, transmission, control, protocol", + doi="10.17487/RFC2197", + } + +@misc{rfc2198, + author="C. Perkins and I. Kouvelas and O. Hodson and V. Hardman and M. Handley and J.C. Bolot and A. Vega-Garcia and S. Fosse-Parisis", + title="{RTP Payload for Redundant Audio Data}", + howpublished="RFC 2198 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2198", + pages="1--11", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6354", +url="https://www.rfc-editor.org/rfc/rfc2198.txt", + key="RFC 2198", + abstract={This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]}, + keywords="RTP-RAD", + doi="10.17487/RFC2198", + } + +@misc{rfc2199, + author="A. Ramos", + title="{Request for Comments Summary RFC Numbers 2100-2199}", + howpublished="RFC 2199 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2199", + pages="1--23", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2199.txt", + key="RFC 2199", + doi="10.17487/RFC2199", + } + +@misc{rfc2200, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2200 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2200", + pages="1--39", + year=1997, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2300", +url="https://www.rfc-editor.org/rfc/rfc2200.txt", + key="RFC 2200", + abstract={A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC2200", + } + +@misc{rfc2201, + author="A. Ballardie", + title="{Core Based Trees (CBT) Multicast Routing Architecture}", + howpublished="RFC 2201 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2201", + pages="1--15", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2201.txt", + key="RFC 2201", + abstract={CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. This memo defines an Experimental Protocol for the Internet community.}, + keywords="IP, Internet, Protocol, IDMR, Inter-Domain", + doi="10.17487/RFC2201", + } + +@misc{rfc2202, + author="P. Cheng and R. Glenn", + title="{Test Cases for HMAC-MD5 and HMAC-SHA-1}", + howpublished="RFC 2202 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2202", + pages="1--9", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2202.txt", + key="RFC 2202", + abstract={This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Hash, Message, Authentications, Codes, message, digest, secure", + doi="10.17487/RFC2202", + } + +@misc{rfc2203, + author="M. Eisler and A. Chiu and L. Ling", + title="{RPCSEC\_GSS Protocol Specification}", + howpublished="RFC 2203 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2203", + pages="1--23", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5403", +url="https://www.rfc-editor.org/rfc/rfc2203.txt", + key="RFC 2203", + abstract={This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). [STANDARDS-TRACK]}, + keywords="RPCSEC-GSS, Remote, Procedure, Call, Generic, Security, Services, API, Application, Programming, Interface", + doi="10.17487/RFC2203", + } + +@misc{rfc2204, + author="D. Nash", + title="{ODETTE File Transfer Protocol}", + howpublished="RFC 2204 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2204", + pages="1--74", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5024", +url="https://www.rfc-editor.org/rfc/rfc2204.txt", + key="RFC 2204", + abstract={This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="ODETTE, FTP, Internet, Motor, Industry, data, exchange", + doi="10.17487/RFC2204", + } + +@misc{rfc2205, + author="R. {Braden (Ed.)} and L. Zhang and S. Berson and S. Herzog and S. Jamin", + title="{Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification}", + howpublished="RFC 2205 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2205", + pages="1--112", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2750, 3936, 4495, 5946, 6437, 6780", +url="https://www.rfc-editor.org/rfc/rfc2205.txt", + key="RFC 2205", + abstract={This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]}, + keywords="RSVP, integrated, services, multicast, unicast, QoS, signaling", + doi="10.17487/RFC2205", + } + +@misc{rfc2206, + author="F. Baker and J. Krawczyk and A. Sastry", + title="{RSVP Management Information Base using SMIv2}", + howpublished="RFC 2206 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2206", + pages="1--64", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2206.txt", + key="RFC 2206", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]}, + keywords="RSVP-MIB", + doi="10.17487/RFC2206", + } + +@misc{rfc2207, + author="L. Berger and T. O'Malley", + title="{RSVP Extensions for IPSEC Data Flows}", + howpublished="RFC 2207 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2207", + pages="1--14", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2207.txt", + key="RFC 2207", + abstract={This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]}, + keywords="RSVP-IPSEC, resource, reservation, QoS, IP, Security", + doi="10.17487/RFC2207", + } + +@misc{rfc2208, + author="A. {Mankin (Ed.)} and F. Baker and B. Braden and S. Bradner and M. O'Dell and A. Romanow and A. Weinrib and L. Zhang", + title="{Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment}", + howpublished="RFC 2208 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2208", + pages="1--6", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2208.txt", + key="RFC 2208", + abstract={This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="RSVP", + doi="10.17487/RFC2208", + } + +@misc{rfc2209, + author="R. Braden and L. Zhang", + title="{Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules}", + howpublished="RFC 2209 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2209", + pages="1--25", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2209.txt", + key="RFC 2209", + abstract={This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="RSVP-MPR, QoS, implementation, algorithms", + doi="10.17487/RFC2209", + } + +@misc{rfc2210, + author="J. Wroclawski", + title="{The Use of RSVP with IETF Integrated Services}", + howpublished="RFC 2210 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2210", + pages="1--33", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2210.txt", + key="RFC 2210", + abstract={This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]}, + keywords="RSVP-IS, Resource, Reservation, Controlled, Load, QOS: Quality of Service", + doi="10.17487/RFC2210", + } + +@misc{rfc2211, + author="J. Wroclawski", + title="{Specification of the Controlled-Load Network Element Service}", + howpublished="RFC 2211 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2211", + pages="1--19", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2211.txt", + key="RFC 2211", + abstract={This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]}, + keywords="QOS: Quality of Service, integrated services", + doi="10.17487/RFC2211", + } + +@misc{rfc2212, + author="S. Shenker and C. Partridge and R. Guerin", + title="{Specification of Guaranteed Quality of Service}", + howpublished="RFC 2212 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2212", + pages="1--20", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2212.txt", + key="RFC 2212", + abstract={This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]}, + keywords="GQOS, QOS, quality of service, integrated services", + doi="10.17487/RFC2212", + } + +@misc{rfc2213, + author="F. Baker and J. Krawczyk and A. Sastry", + title="{Integrated Services Management Information Base using SMIv2}", + howpublished="RFC 2213 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2213", + pages="1--21", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2213.txt", + key="RFC 2213", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]}, + keywords="MIB", + doi="10.17487/RFC2213", + } + +@misc{rfc2214, + author="F. Baker and J. Krawczyk and A. Sastry", + title="{Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2}", + howpublished="RFC 2214 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2214", + pages="1--9", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2214.txt", + key="RFC 2214", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. [STANDARDS-TRACK]}, + keywords="MIB, attributes, interface, network, protocol", + doi="10.17487/RFC2214", + } + +@misc{rfc2215, + author="S. Shenker and J. Wroclawski", + title="{General Characterization Parameters for Integrated Service Network Elements}", + howpublished="RFC 2215 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2215", + pages="1--16", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2215.txt", + key="RFC 2215", + abstract={This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK]}, + keywords="QOS, Quality of service", + doi="10.17487/RFC2215", + } + +@misc{rfc2216, + author="S. Shenker and J. Wroclawski", + title="{Network Element Service Specification Template}", + howpublished="RFC 2216 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2216", + pages="1--22", + year=1997, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2216.txt", + key="RFC 2216", + abstract={This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a ``template'' which service specification documents should follow. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="QOS, Quality, of, Service, Control", + doi="10.17487/RFC2216", + } + +@misc{rfc2217, + author="G. Clark", + title="{Telnet Com Port Control Option}", + howpublished="RFC 2217 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2217", + pages="1--14", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2217.txt", + key="RFC 2217", + abstract={This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TOPT-COMPORT, remote, login, host", + doi="10.17487/RFC2217", + } + +@misc{rfc2218, + author="T. Genovese and B. Jennings", + title="{A Common Schema for the Internet White Pages Service}", + howpublished="RFC 2218 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2218", + pages="1--8", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2218.txt", + key="RFC 2218", + abstract={This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. [STANDARDS-TRACK]}, + keywords="IWPS, information, user", + doi="10.17487/RFC2218", + } + +@misc{rfc2219, + author="M. Hamilton and R. Wright", + title="{Use of DNS Aliases for Network Services}", + howpublished="RFC 2219 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2219", + pages="1--8", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2219.txt", + key="RFC 2219", + abstract={It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC- 1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions f or improvements.}, + keywords="domain, name, system, symbolic", + doi="10.17487/RFC2219", + } + +@misc{rfc2220, + author="R. Guenther", + title="{The Application/MARC Content-type}", + howpublished="RFC 2220 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2220", + pages="1--4", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2220.txt", + key="RFC 2220", + abstract={This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="APP-MARC, media-type, machine, readable, cataloging, records", + doi="10.17487/RFC2220", + } + +@misc{rfc2221, + author="M. Gahrns", + title="{IMAP4 Login Referrals}", + howpublished="RFC 2221 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2221", + pages="1--5", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2221.txt", + key="RFC 2221", + abstract={When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]}, + keywords="IMAP4LOGIN, Internet, Message, Access, Protocol, server", + doi="10.17487/RFC2221", + } + +@misc{rfc2222, + author="J. Myers", + title="{Simple Authentication and Security Layer (SASL)}", + howpublished="RFC 2222 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2222", + pages="1--16", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4422, 4752, updated by RFC 2444", +url="https://www.rfc-editor.org/rfc/rfc2222.txt", + key="RFC 2222", + abstract={This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]}, + keywords="SASL, encryption, protocol, specific", + doi="10.17487/RFC2222", + } + +@misc{rfc2223, + author="J. Postel and J. Reynolds", + title="{Instructions to RFC Authors}", + howpublished="RFC 2223 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2223", + pages="1--20", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7322, updated by RFCs 5741, 6949", +url="https://www.rfc-editor.org/rfc/rfc2223.txt", + key="RFC 2223", + abstract={This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Request, For, Comment", + doi="10.17487/RFC2223", + } + +@misc{rfc2224, + author="B. Callaghan", + title="{NFS URL Scheme}", + howpublished="RFC 2224 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2224", + pages="1--11", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2224.txt", + key="RFC 2224", + abstract={A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, ``Uniform Resource Locators (URL)''. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="NFS-URL, Universal, Resource, Locators, Network, File, System, syntax, directories", + doi="10.17487/RFC2224", + } + +@misc{rfc2225, + author="M. Laubach and J. Halpern", + title="{Classical IP and ARP over ATM}", + howpublished="RFC 2225 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2225", + pages="1--28", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc2225.txt", + key="RFC 2225", + abstract={This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]}, + keywords="IP-ATM, Internet, protocol, address, resolution, asynchronous,transfer, mode", + doi="10.17487/RFC2225", + } + +@misc{rfc2226, + author="T. Smith and G. Armitage", + title="{IP Broadcast over ATM Networks}", + howpublished="RFC 2226 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2226", + pages="1--14", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2226.txt", + key="RFC 2226", + abstract={This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. [STANDARDS-TRACK]}, + keywords="Internet, Protocol, Asynchronous, Transfer, Mode", + doi="10.17487/RFC2226", + } + +@misc{rfc2227, + author="J. Mogul and P. Leach", + title="{Simple Hit-Metering and Usage-Limiting for HTTP}", + howpublished="RFC 2227 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2227", + pages="1--37", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2227.txt", + key="RFC 2227", + abstract={This document proposes a simple extension to HTTP, using a new ``Meter'' header. [STANDARDS-TRACK]}, + keywords="Hypertext, Transfer, Protocol, extension", + doi="10.17487/RFC2227", + } + +@misc{rfc2228, + author="M. Horowitz and S. Lunt", + title="{FTP Security Extensions}", + howpublished="RFC 2228 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2228", + pages="1--27", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2228.txt", + key="RFC 2228", + abstract={This document defines extensions to the FTP specification STD 9, RFC}, + keywords="FTPSECEXT, file, transfer, protocol, authentication, encoding", + doi="10.17487/RFC2228", + } + +@misc{rfc2229, + author="R. Faith and B. Martin", + title="{A Dictionary Server Protocol}", + howpublished="RFC 2229 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2229", + pages="1--30", + year=1997, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2229.txt", + key="RFC 2229", + abstract={The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="DSP, DICT, TCP, Transmission, Control, Protocol, database, definitions", + doi="10.17487/RFC2229", + } + +@misc{rfc2230, + author="R. Atkinson", + title="{Key Exchange Delegation Record for the DNS}", + howpublished="RFC 2230 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2230", + pages="1--11", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2230.txt", + key="RFC 2230", + abstract={This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="KEYX-DNS, Domain, Name, System, RR, Resource, Record, KX", + doi="10.17487/RFC2230", + } + +@misc{rfc2231, + author="N. Freed and K. Moore", + title="{MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations}", + howpublished="RFC 2231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2231", + pages="1--10", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2231.txt", + key="RFC 2231", + abstract={This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]}, + keywords="MIME-EXT, Mail, Multimedia, EMail", + doi="10.17487/RFC2231", + } + +@misc{rfc2232, + author="B. {Clouston (Ed.)} and B. {Moore (Ed.)}", + title="{Definitions of Managed Objects for DLUR using SMIv2}", + howpublished="RFC 2232 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2232", + pages="1--21", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2232.txt", + key="RFC 2232", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]}, + keywords="DLUR-MIB, Management, Information Base, MIB, Dependent LU Requester, APPN, Advanced, Peek, to Peek Networking", + doi="10.17487/RFC2232", + } + +@misc{rfc2233, + author="K. McCloghrie and F. Kastenholz", + title="{The Interfaces Group MIB using SMIv2}", + howpublished="RFC 2233 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2233", + pages="1--66", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2863", +url="https://www.rfc-editor.org/rfc/rfc2233.txt", + key="RFC 2233", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK]}, + keywords="INTERGRMIB, Management, Information, Base, Network", + doi="10.17487/RFC2233", + } + +@misc{rfc2234, + author="D. {Crocker (Ed.)} and P. Overell", + title="{Augmented BNF for Syntax Specifications: ABNF}", + howpublished="RFC 2234 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2234", + pages="1--14", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4234", +url="https://www.rfc-editor.org/rfc/rfc2234.txt", + key="RFC 2234", + abstract={In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]}, + keywords="ABNF, Augmented, Backus-Naur, Form, electronic, mail", + doi="10.17487/RFC2234", + } + +@misc{rfc2235, + author="R. Zakon", + title="{Hobbes' Internet Timeline}", + howpublished="RFC 2235 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2235", + pages="1--22", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2235.txt", + key="RFC 2235", + abstract={This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="events, technologies, history", + doi="10.17487/RFC2235", + } + +@misc{rfc2236, + author="W. Fenner", + title="{Internet Group Management Protocol, Version 2}", + howpublished="RFC 2236 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2236", + pages="1--24", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3376", +url="https://www.rfc-editor.org/rfc/rfc2236.txt", + key="RFC 2236", + abstract={This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK]}, + keywords="IGMP, IGMP, multicast, routing, IP, Internet, Protocol", + doi="10.17487/RFC2236", + } + +@misc{rfc2237, + author="K. Tamaru", + title="{Japanese Character Encoding for Internet Messages}", + howpublished="RFC 2237 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2237", + pages="1--6", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2237.txt", + key="RFC 2237", + abstract={This memo defines an encoding scheme for the Japanese Characters, describes ``ISO-2022-JP-1'', which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="eletronic, mail, character, set, scheme", + doi="10.17487/RFC2237", + } + +@misc{rfc2238, + author="B. {Clouston (Ed.)} and B. {Moore (Ed.)}", + title="{Definitions of Managed Objects for HPR using SMIv2}", + howpublished="RFC 2238 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2238", + pages="1--35", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2238.txt", + key="RFC 2238", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]}, + keywords="HPR-MIB, MIB, Management, Information, Base, high, performance, routing", + doi="10.17487/RFC2238", + } + +@misc{rfc2239, + author="K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie and S. Roberts", + title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2}", + howpublished="RFC 2239 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2239", + pages="1--43", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2668", +url="https://www.rfc-editor.org/rfc/rfc2239.txt", + key="RFC 2239", + abstract={This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, ``10 \& 100 Mb/s Management,'' October 26, 1995. [STANDARDS-TRACK]}, + keywords="MAUS-MIB", + doi="10.17487/RFC2239", + } + +@misc{rfc2240, + author="O. Vaughan", + title="{A Legal Basis for Domain Name Allocation}", + howpublished="RFC 2240 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2240", + pages="1--7", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2352", +url="https://www.rfc-editor.org/rfc/rfc2240.txt", + key="RFC 2240", + abstract={The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="DNS", + doi="10.17487/RFC2240", + } + +@misc{rfc2241, + author="D. Provan", + title="{DHCP Options for Novell Directory Services}", + howpublished="RFC 2241 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2241", + pages="1--5", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2241.txt", + key="RFC 2241", + abstract={This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. [STANDARDS-TRACK]}, + keywords="DHCP-NDS, NDS", + doi="10.17487/RFC2241", + } + +@misc{rfc2242, + author="R. Droms and K. Fong", + title="{NetWare/IP Domain Name and Information}", + howpublished="RFC 2242 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2242", + pages="1--6", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2242.txt", + key="RFC 2242", + abstract={This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]}, + keywords="NETWAREIP, DHCP", + doi="10.17487/RFC2242", + } + +@misc{rfc2243, + author="C. Metz", + title="{OTP Extended Responses}", + howpublished="RFC 2243 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2243", + pages="1--10", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2243.txt", + key="RFC 2243", + abstract={This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. [STANDARDS-TRACK]}, + keywords="OTP-ER, One, Time, Password", + doi="10.17487/RFC2243", + } + +@misc{rfc2244, + author="C. Newman and J. G. Myers", + title="{ACAP -- Application Configuration Access Protocol}", + howpublished="RFC 2244 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2244", + pages="1--71", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6075", +url="https://www.rfc-editor.org/rfc/rfc2244.txt", + key="RFC 2244", + abstract={The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK]}, + keywords="ACAP, URL, Uniform, Resource, Locator", + doi="10.17487/RFC2244", + } + +@misc{rfc2245, + author="C. Newman", + title="{Anonymous SASL Mechanism}", + howpublished="RFC 2245 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2245", + pages="1--5", + year=1997, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4505", +url="https://www.rfc-editor.org/rfc/rfc2245.txt", + key="RFC 2245", + abstract={As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. [STANDARDS-TRACK]}, + keywords="SASL-ANON, Simple, Authentication, Security, Layer", + doi="10.17487/RFC2245", + } + +@misc{rfc2246, + author="T. Dierks and C. Allen", + title="{The TLS Protocol Version 1.0}", + howpublished="RFC 2246 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2246", + pages="1--80", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4346, updated by RFCs 3546, 5746, 6176, 7465, 7507, 7919", +url="https://www.rfc-editor.org/rfc/rfc2246.txt", + key="RFC 2246", + abstract={This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]}, + keywords="transport, protocol, layer, authentication, privacy", + doi="10.17487/RFC2246", + } + +@misc{rfc2247, + author="S. Kille and M. Wahl and A. Grimstad and R. Huber and S. Sataluri", + title="{Using Domains in LDAP/X.500 Distinguished Names}", + howpublished="RFC 2247 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2247", + pages="1--7", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4519, 4524", +url="https://www.rfc-editor.org/rfc/rfc2247.txt", + key="RFC 2247", + abstract={This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol, DNS, Domain, name, system", + doi="10.17487/RFC2247", + } + +@misc{rfc2248, + author="N. Freed and S. Kille", + title="{Network Services Monitoring MIB}", + howpublished="RFC 2248 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2248", + pages="1--19", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2788", +url="https://www.rfc-editor.org/rfc/rfc2248.txt", + key="RFC 2248", + abstract={This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]}, + keywords="NSM-MIB, Management, Information, Base, SNMP, Simple, Network, Management, Protocol", + doi="10.17487/RFC2248", + } + +@misc{rfc2249, + author="N. Freed and S. Kille", + title="{Mail Monitoring MIB}", + howpublished="RFC 2249 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2249", + pages="1--28", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2789", +url="https://www.rfc-editor.org/rfc/rfc2249.txt", + key="RFC 2249", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [STANDARDS-TRACK]}, + keywords="MAIL-MIB, Management, Information, Base, Message, Transfer, Agents", + doi="10.17487/RFC2249", + } + +@misc{rfc2250, + author="D. Hoffman and G. Fernando and V. Goyal and M. Civanlar", + title="{RTP Payload Format for MPEG1/MPEG2 Video}", + howpublished="RFC 2250 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2250", + pages="1--16", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2250.txt", + key="RFC 2250", + abstract={This memo describes a packetization scheme for MPEG video and audio streams. [STANDARDS-TRACK] The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="RTP-MPEG, Real-Time, Transport, Protocol, Audio, System, Streams", + doi="10.17487/RFC2250", + } + +@misc{rfc2251, + author="M. Wahl and T. Howes and S. Kille", + title="{Lightweight Directory Access Protocol (v3)}", + howpublished="RFC 2251 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2251", + pages="1--50", + year=1997, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4510, 4511, 4513, 4512, updated by RFCs 3377, 3771", +url="https://www.rfc-editor.org/rfc/rfc2251.txt", + key="RFC 2251", + abstract={The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]}, + keywords="LDAPV3, LDAv3, x.500", + doi="10.17487/RFC2251", + } + +@misc{rfc2252, + author="M. Wahl and A. Coulbeck and T. Howes and S. Kille", + title="{Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions}", + howpublished="RFC 2252 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2252", + pages="1--32", + year=1997, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4510, 4517, 4523, 4512, updated by RFC 3377", +url="https://www.rfc-editor.org/rfc/rfc2252.txt", + key="RFC 2252", + abstract={This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]}, + keywords="LDAP3-ATD, LDAv3, x.500, syntax", + doi="10.17487/RFC2252", + } + +@misc{rfc2253, + author="M. Wahl and S. Kille and T. Howes", + title="{Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names}", + howpublished="RFC 2253 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2253", + pages="1--10", + year=1997, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4510, 4514, updated by RFC 3377", +url="https://www.rfc-editor.org/rfc/rfc2253.txt", + key="RFC 2253", + abstract={This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]}, + keywords="LDAP3-UTF8, LDAPv3, x.500, ASN.1, string, format", + doi="10.17487/RFC2253", + } + +@misc{rfc2254, + author="T. Howes", + title="{The String Representation of LDAP Search Filters}", + howpublished="RFC 2254 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2254", + pages="1--8", + year=1997, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4510, 4515, updated by RFC 3377", +url="https://www.rfc-editor.org/rfc/rfc2254.txt", + key="RFC 2254", + abstract={This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]}, + keywords="STR-LDAP, LDAPv3, x.500, ASN.1, string, format", + doi="10.17487/RFC2254", + } + +@misc{rfc2255, + author="T. Howes and M. Smith", + title="{The LDAP URL Format}", + howpublished="RFC 2255 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2255", + pages="1--10", + year=1997, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4510, 4516, updated by RFC 3377", +url="https://www.rfc-editor.org/rfc/rfc2255.txt", + key="RFC 2255", + abstract={This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]}, + keywords="LDAP-URL, Lightweight, Directory, Access, Protocol, Universal, Resource, Locator", + doi="10.17487/RFC2255", + } + +@misc{rfc2256, + author="M. Wahl", + title="{A Summary of the X.500(96) User Schema for use with LDAPv3}", + howpublished="RFC 2256 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2256", + pages="1--20", + year=1997, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4517, 4519, 4523, 4512, 4510, updated by RFC 3377", +url="https://www.rfc-editor.org/rfc/rfc2256.txt", + key="RFC 2256", + abstract={This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS-TRACK]}, + keywords="Lightweight, Directory, Access, Protocol, syntax", + doi="10.17487/RFC2256", + } + +@misc{rfc2257, + author="M. Daniele and B. Wijnen and D. Francisco", + title="{Agent Extensibility (AgentX) Protocol Version 1}", + howpublished="RFC 2257 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2257", + pages="1--80", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2741", +url="https://www.rfc-editor.org/rfc/rfc2257.txt", + key="RFC 2257", + abstract={This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]}, + keywords="AGENTX, SNMP, Simple, Network, Management, Protocol, MIB, Information, Base", + doi="10.17487/RFC2257", + } + +@misc{rfc2258, + author="J. Ordille", + title="{Internet Nomenclator Project}", + howpublished="RFC 2258 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2258", + pages="1--15", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2258.txt", + key="RFC 2258", + abstract={The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="Database, Server, CCSO, Computer, Communications, Services, Office", + doi="10.17487/RFC2258", + } + +@misc{rfc2259, + author="J. Elliott and J. Ordille", + title="{Simple Nomenclator Query Protocol (SNQP)}", + howpublished="RFC 2259 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2259", + pages="1--30", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2259.txt", + key="RFC 2259", + abstract={The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind}, + keywords="SNQP, Data, Repositories, Client, Server", + doi="10.17487/RFC2259", + } + +@misc{rfc2260, + author="T. Bates and Y. Rekhter", + title="{Scalable Support for Multi-homed Multi-provider Connectivity}", + howpublished="RFC 2260 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2260", + pages="1--12", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2260.txt", + key="RFC 2260", + abstract={This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="ISP, Internet, Service, Provider, Routing", + doi="10.17487/RFC2260", + } + +@misc{rfc2261, + author="D. Harrington and R. Presuhn and B. Wijnen", + title="{An Architecture for Describing SNMP Management Frameworks}", + howpublished="RFC 2261 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2261", + pages="1--56", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2271", +url="https://www.rfc-editor.org/rfc/rfc2261.txt", + key="RFC 2261", + abstract={This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]}, + keywords="Simple, Network, Management, Protocol, Message, Network, Management, Protocol, security, access, control, snmpv3", + doi="10.17487/RFC2261", + } + +@misc{rfc2262, + author="J. Case and D. Harrington and R. Presuhn and B. Wijnen", + title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 2262 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2262", + pages="1--39", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2272", +url="https://www.rfc-editor.org/rfc/rfc2262.txt", + key="RFC 2262", + abstract={This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]}, + keywords="architecture, SNMPv3, multiple, versions", + doi="10.17487/RFC2262", + } + +@misc{rfc2263, + author="D. Levi and P. Meyer and B. Stewart", + title="{SNMPv3 Applications}", + howpublished="RFC 2263 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2263", + pages="1--70", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2273", +url="https://www.rfc-editor.org/rfc/rfc2263.txt", + key="RFC 2263", + abstract={This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]}, + keywords="Simple, Network, Management, Protocol, operations, notification, filtering, proxy, forwarding", + doi="10.17487/RFC2263", + } + +@misc{rfc2264, + author="U. Blumenthal and B. Wijnen", + title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}", + howpublished="RFC 2264 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2264", + pages="1--76", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2274", +url="https://www.rfc-editor.org/rfc/rfc2264.txt", + key="RFC 2264", + abstract={This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]}, + keywords="architecture, message, level", + doi="10.17487/RFC2264", + } + +@misc{rfc2265, + author="B. Wijnen and R. Presuhn and K. McCloghrie", + title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 2265 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2265", + pages="1--36", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2275", +url="https://www.rfc-editor.org/rfc/rfc2265.txt", + key="RFC 2265", + abstract={This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]}, + keywords="SNMPV3, Architecture", + doi="10.17487/RFC2265", + } + +@misc{rfc2266, + author="J. Flick", + title="{Definitions of Managed Objects for IEEE 802.12 Repeater Devices}", + howpublished="RFC 2266 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2266", + pages="1--56", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2266.txt", + key="RFC 2266", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network repeaters based on IEEE 802.12. [STANDARDS-TRACK]}, + keywords="MIB, Management, Information, Base", + doi="10.17487/RFC2266", + } + +@misc{rfc2267, + author="P. Ferguson and D. Senie", + title="{Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing}", + howpublished="RFC 2267 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2267", + pages="1--10", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2827", +url="https://www.rfc-editor.org/rfc/rfc2267.txt", + key="RFC 2267", + abstract={This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="ISP, Internet, Service, Provider, Internet, Protocol, DOS", + doi="10.17487/RFC2267", + } + +@misc{rfc2268, + author="R. Rivest", + title="{A Description of the RC2(r) Encryption Algorithm}", + howpublished="RFC 2268 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2268", + pages="1--11", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2268.txt", + key="RFC 2268", + abstract={This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="RC2-ENCRP, encryption, secre, key rsa", + doi="10.17487/RFC2268", + } + +@misc{rfc2269, + author="G. Armitage", + title="{Using the MARS Model in non-ATM NBMA Networks}", + howpublished="RFC 2269 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2269", + pages="1--6", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2269.txt", + key="RFC 2269", + abstract={This document is intended to state the obvious equivalences, and explain the less obvious implications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="Asynchronous, Transfer, Mode, Multicast, Address, Resolution, Server, IP, Internet, Protocol", + doi="10.17487/RFC2269", + } + +@misc{rfc2270, + author="J. Stewart and T. Bates and R. Chandra and E. Chen", + title="{Using a Dedicated AS for Sites Homed to a Single Provider}", + howpublished="RFC 2270 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2270", + pages="1--6", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2270.txt", + key="RFC 2270", + abstract={With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="Autonomous, System, BGP4, Border, Gateway, Protocol, ISP, Internet, Service", + doi="10.17487/RFC2270", + } + +@misc{rfc2271, + author="D. Harrington and R. Presuhn and B. Wijnen", + title="{An Architecture for Describing SNMP Management Frameworks}", + howpublished="RFC 2271 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2271", + pages="1--56", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2571", +url="https://www.rfc-editor.org/rfc/rfc2271.txt", + key="RFC 2271", + abstract={This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]}, + keywords="Simple, Network, Management, Protocol, Message, Network, Management, Protocol, security, access, control, snmpv3", + doi="10.17487/RFC2271", + } + +@misc{rfc2272, + author="J. Case and D. Harrington and R. Presuhn and B. Wijnen", + title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 2272 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2272", + pages="1--39", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2572", +url="https://www.rfc-editor.org/rfc/rfc2272.txt", + key="RFC 2272", + abstract={This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]}, + keywords="SNMPv3, architecture, SNMPv3, multiple, versions", + doi="10.17487/RFC2272", + } + +@misc{rfc2273, + author="D. Levi and P. Meyer and B. Stewart", + title="{SNMPv3 Applications}", + howpublished="RFC 2273 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2273", + pages="1--70", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2573", +url="https://www.rfc-editor.org/rfc/rfc2273.txt", + key="RFC 2273", + abstract={This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]}, + keywords="Simple, Network, Management, Protocol, operations, notification, filtering, proxy, forwarding", + doi="10.17487/RFC2273", + } + +@misc{rfc2274, + author="U. Blumenthal and B. Wijnen", + title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}", + howpublished="RFC 2274 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2274", + pages="1--76", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2574", +url="https://www.rfc-editor.org/rfc/rfc2274.txt", + key="RFC 2274", + abstract={This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]}, + keywords="architecture, message, level", + doi="10.17487/RFC2274", + } + +@misc{rfc2275, + author="B. Wijnen and R. Presuhn and K. McCloghrie", + title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 2275 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2275", + pages="1--36", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2575", +url="https://www.rfc-editor.org/rfc/rfc2275.txt", + key="RFC 2275", + abstract={This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]}, + keywords="SNMPV3, Architecture", + doi="10.17487/RFC2275", + } + +@misc{rfc2276, + author="K. Sollins", + title="{Architectural Principles of Uniform Resource Name Resolution}", + howpublished="RFC 2276 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2276", + pages="1--24", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3401", +url="https://www.rfc-editor.org/rfc/rfc2276.txt", + key="RFC 2276", + abstract={This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="URCs, URN, URLs, Uniform, Resource, Locators, Characteristics", + doi="10.17487/RFC2276", + } + +@misc{rfc2277, + author="H. Alvestrand", + title="{IETF Policy on Character Sets and Languages}", + howpublished="RFC 2277 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2277", + pages="1--9", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2277.txt", + key="RFC 2277", + abstract={This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="charset", + doi="10.17487/RFC2277", + } + +@misc{rfc2278, + author="N. Freed and J. Postel", + title="{IANA Charset Registration Procedures}", + howpublished="RFC 2278 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2278", + pages="1--10", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2978", +url="https://www.rfc-editor.org/rfc/rfc2278.txt", + key="RFC 2278", + abstract={MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="character, set, mime, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2278", + } + +@misc{rfc2279, + author="F. Yergeau", + title="{UTF-8, a transformation format of ISO 10646}", + howpublished="RFC 2279 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2279", + pages="1--10", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3629", +url="https://www.rfc-editor.org/rfc/rfc2279.txt", + key="RFC 2279", + abstract={UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]}, + keywords="UTF-8, UCS, Transformation, Format", + doi="10.17487/RFC2279", + } + +@misc{rfc2280, + author="C. Alaettinoglu and T. Bates and E. Gerich and D. Karrenberg and D. Meyer and M. Terpstra and C. Villamizar", + title="{Routing Policy Specification Language (RPSL)}", + howpublished="RFC 2280 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2280", + pages="1--53", + year=1998, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2622", +url="https://www.rfc-editor.org/rfc/rfc2280.txt", + key="RFC 2280", + abstract={This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]}, + keywords="RPSL, network, operator, AS, autonomous, system, database", + doi="10.17487/RFC2280", + } + +@misc{rfc2281, + author="T. Li and B. Cole and P. Morton and D. Li", + title="{Cisco Hot Standby Router Protocol (HSRP)}", + howpublished="RFC 2281 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2281", + pages="1--17", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2281.txt", + key="RFC 2281", + abstract={The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="HSRP", + doi="10.17487/RFC2281", + } + +@misc{rfc2282, + author="J. Galvin", + title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}", + howpublished="RFC 2282 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2282", + pages="1--14", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2727", +url="https://www.rfc-editor.org/rfc/rfc2282.txt", + key="RFC 2282", + abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet, Architecture, Board, Engineering, Steering, Group", + doi="10.17487/RFC2282", + } + +@misc{rfc2283, + author="T. Bates and R. Chandra and D. Katz and Y. Rekhter", + title="{Multiprotocol Extensions for BGP-4}", + howpublished="RFC 2283 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2283", + pages="1--9", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2858", +url="https://www.rfc-editor.org/rfc/rfc2283.txt", + key="RFC 2283", + abstract={This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]}, + keywords="MEXT-BGP4, Border, gateway, protocol, router, network, layer", + doi="10.17487/RFC2283", + } + +@misc{rfc2284, + author="L. Blunk and J. Vollbrecht", + title="{PPP Extensible Authentication Protocol (EAP)}", + howpublished="RFC 2284 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2284", + pages="1--15", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3748, updated by RFC 2484", +url="https://www.rfc-editor.org/rfc/rfc2284.txt", + key="RFC 2284", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. [STANDARDS-TRACK]}, + keywords="PPP-EAP, point-to-point, authentication", + doi="10.17487/RFC2284", + } + +@misc{rfc2285, + author="R. Mandeville", + title="{Benchmarking Terminology for LAN Switching Devices}", + howpublished="RFC 2285 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2285", + pages="1--25", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2285.txt", + key="RFC 2285", + abstract={This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="local, area, network, MAC, Medium, Access, Control, layer", + doi="10.17487/RFC2285", + } + +@misc{rfc2286, + author="J. Kapp", + title="{Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128}", + howpublished="RFC 2286 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2286", + pages="1--7", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2286.txt", + key="RFC 2286", + abstract={This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="has, authentication, message, IP, Internet, Protocol, codes", + doi="10.17487/RFC2286", + } + +@misc{rfc2287, + author="C. Krupczak and J. Saperia", + title="{Definitions of System-Level Managed Objects for Applications}", + howpublished="RFC 2287 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2287", + pages="1--44", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2287.txt", + key="RFC 2287", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]}, + keywords="SLM-APP, mib, management, information, base", + doi="10.17487/RFC2287", + } + +@misc{rfc2288, + author="C. Lynch and C. Preston and R. Daniel", + title="{Using Existing Bibliographic Identifiers as Uniform Resource Names}", + howpublished="RFC 2288 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2288", + pages="1--10", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2288.txt", + key="RFC 2288", + abstract={This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="URNs, Syntax, framework", + doi="10.17487/RFC2288", + } + +@misc{rfc2289, + author="N. Haller and C. Metz and P. Nesser and M. Straw", + title="{A One-Time Password System}", + howpublished="RFC 2289 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2289", + pages="1--25", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2289.txt", + key="RFC 2289", + abstract={This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS-TRACK]}, + keywords="ONE-PASS, authentication, OTP, replay, attach", + doi="10.17487/RFC2289", + } + +@misc{rfc2290, + author="J. Solomon and S. Glass", + title="{Mobile-IPv4 Configuration Option for PPP IPCP}", + howpublished="RFC 2290 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2290", + pages="1--17", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2794", +url="https://www.rfc-editor.org/rfc/rfc2290.txt", + key="RFC 2290", + abstract={Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. [STANDARDS-TRACK]}, + keywords="Internet, protocol, point-to-point, control, address", + doi="10.17487/RFC2290", + } + +@misc{rfc2291, + author="J. Slein and F. Vitali and E. Whitehead and D. Durand", + title="{Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web}", + howpublished="RFC 2291 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2291", + pages="1--21", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2291.txt", + key="RFC 2291", + abstract={This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="WWW, remote, editing, locking, mechanism", + doi="10.17487/RFC2291", + } + +@misc{rfc2292, + author="W. Stevens and M. Thomas", + title="{Advanced Sockets API for IPv6}", + howpublished="RFC 2292 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2292", + pages="1--67", + year=1998, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3542", +url="https://www.rfc-editor.org/rfc/rfc2292.txt", + key="RFC 2292", + abstract={The current document defines some the ``advanced'' features of the sockets API that are required for applications to take advantage of additional features of IPv6. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="application, program, interface", + doi="10.17487/RFC2292", + } + +@misc{rfc2293, + author="S. Kille", + title="{Representing Tables and Subtrees in the X.500 Directory}", + howpublished="RFC 2293 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2293", + pages="1--8", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2293.txt", + key="RFC 2293", + abstract={This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. [STANDARDS-TRCK]}, + keywords="SUBTABLE, mapping, distinguished, name", + doi="10.17487/RFC2293", + } + +@misc{rfc2294, + author="S. Kille", + title="{Representing the O/R Address hierarchy in the X.500 Directory Information Tree}", + howpublished="RFC 2294 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2294", + pages="1--13", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2294.txt", + key="RFC 2294", + abstract={This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK]}, + keywords="OR-ADD, routing, mapping, dit", + doi="10.17487/RFC2294", + } + +@misc{rfc2295, + author="K. Holtman and A. Mutz", + title="{Transparent Content Negotiation in HTTP}", + howpublished="RFC 2295 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2295", + pages="1--58", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2295.txt", + key="RFC 2295", + abstract={HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="TCN-HTTP, Hyper, Text, Transfer, protocol, URL, Uniform, Resource, Locators", + doi="10.17487/RFC2295", + } + +@misc{rfc2296, + author="K. Holtman and A. Mutz", + title="{HTTP Remote Variant Selection Algorithm -- RVSA/1.0}", + howpublished="RFC 2296 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2296", + pages="1--13", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2296.txt", + key="RFC 2296", + abstract={HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="HTTP-RVSA, Hyper, Text, Transfer, protocol, URL, Uniform, Resource, Locators", + doi="10.17487/RFC2296", + } + +@misc{rfc2297, + author="P. Newman and W. Edwards and R. Hinden and E. Hoffman and F. Ching Liaw and T. Lyon and G. Minshall", + title="{Ipsilon's General Switch Management Protocol Specification Version 2.0}", + howpublished="RFC 2297 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2297", + pages="1--109", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2297.txt", + key="RFC 2297", + abstract={This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987]. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="GSMP, gsmp, atm, asynchronous, transfer, mode", + doi="10.17487/RFC2297", + } + +@misc{rfc2298, + author="R. Fajman", + title="{An Extensible Message Format for Message Disposition Notifications}", + howpublished="RFC 2298 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2298", + pages="1--28", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3798", +url="https://www.rfc-editor.org/rfc/rfc2298.txt", + key="RFC 2298", + abstract={This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK]}, + keywords="EMF-MDN, MDN, media-type, MIME, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2298", + } + +@misc{rfc2299, + author="A. Ramos", + title="{Request for Comments Summary}", + howpublished="RFC 2299 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2299", + pages="1--24", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2299.txt", + key="RFC 2299", + doi="10.17487/RFC2299", + } + +@misc{rfc2300, + author="J. Postel", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2300 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2300", + pages="1--59", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2400", +url="https://www.rfc-editor.org/rfc/rfc2300.txt", + key="RFC 2300", + abstract={A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC2300", + } + +@misc{rfc2301, + author="L. McIntyre and S. Zilles and R. Buckley and D. Venable and G. Parsons and J. Rafferty", + title="{File Format for Internet Fax}", + howpublished="RFC 2301 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2301", + pages="1--77", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3949", +url="https://www.rfc-editor.org/rfc/rfc2301.txt", + key="RFC 2301", + abstract={This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK]}, + keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions", + doi="10.17487/RFC2301", + } + +@misc{rfc2302, + author="G. Parsons and J. Rafferty and S. Zilles", + title="{Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration}", + howpublished="RFC 2302 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2302", + pages="1--8", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3302", +url="https://www.rfc-editor.org/rfc/rfc2302.txt", + key="RFC 2302", + abstract={This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]}, + keywords="TIFF, Multipurpose, Internet, Mail, extensions", + doi="10.17487/RFC2302", + } + +@misc{rfc2303, + author="C. Allocchio", + title="{Minimal PSTN address format in Internet Mail}", + howpublished="RFC 2303 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2303", + pages="1--8", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3191", +url="https://www.rfc-editor.org/rfc/rfc2303.txt", + key="RFC 2303", + abstract={This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]}, + keywords="MIN-PSTN, e-mail, service", + doi="10.17487/RFC2303", + } + +@misc{rfc2304, + author="C. Allocchio", + title="{Minimal FAX address format in Internet Mail}", + howpublished="RFC 2304 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2304", + pages="1--8", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3192", +url="https://www.rfc-editor.org/rfc/rfc2304.txt", + key="RFC 2304", + abstract={This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]}, + keywords="MINFAX-IM, encoding, facsimile, e-mail", + doi="10.17487/RFC2304", + } + +@misc{rfc2305, + author="K. Toyoda and H. Ohno and J. Murai and D. Wing", + title="{A Simple Mode of Facsimile Using Internet Mail}", + howpublished="RFC 2305 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2305", + pages="1--13", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3965", +url="https://www.rfc-editor.org/rfc/rfc2305.txt", + key="RFC 2305", + abstract={This specification provides for ``simple mode'' carriage of facsimile data over the Internet. [STANDARDS-TRACK]}, + keywords="SMFAX-IM, data, file, format, e-mail", + doi="10.17487/RFC2305", + } + +@misc{rfc2306, + author="G. Parsons and J. Rafferty", + title="{Tag Image File Format (TIFF) - F Profile for Facsimile}", + howpublished="RFC 2306 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2306", + pages="1--25", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2306.txt", + key="RFC 2306", + abstract={This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="file, format, storage", + doi="10.17487/RFC2306", + } + +@misc{rfc2307, + author="L. Howard", + title="{An Approach for Using LDAP as a Network Information Service}", + howpublished="RFC 2307 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2307", + pages="1--21", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2307.txt", + key="RFC 2307", + abstract={This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="LDAP-NIS, lightweight, directory, access, protocol, unix, mapping", + doi="10.17487/RFC2307", + } + +@misc{rfc2308, + author="M. Andrews", + title="{Negative Caching of DNS Queries (DNS NCACHE)}", + howpublished="RFC 2308 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2308", + pages="1--19", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4035, 4033, 4034, 6604, 8020", +url="https://www.rfc-editor.org/rfc/rfc2308.txt", + key="RFC 2308", + abstract={RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]}, + keywords="DNS-NCACHE, Domain, Name, System, negative", + doi="10.17487/RFC2308", + } + +@misc{rfc2309, + author="B. Braden and D. Clark and J. Crowcroft and B. Davie and S. Deering and D. Estrin and S. Floyd and V. Jacobson and G. Minshall and C. Partridge and L. Peterson and K. Ramakrishnan and S. Shenker and J. Wroclawski and L. Zhang", + title="{Recommendations on Queue Management and Congestion Avoidance in the Internet}", + howpublished="RFC 2309 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2309", + pages="1--17", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7567, updated by RFC 7141", +url="https://www.rfc-editor.org/rfc/rfc2309.txt", + key="RFC 2309", + abstract={This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="performance, router, deployment", + doi="10.17487/RFC2309", + } + +@misc{rfc2310, + author="K. Holtman", + title="{The Safe Response Header Field}", + howpublished="RFC 2310 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2310", + pages="1--5", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2310.txt", + key="RFC 2310", + abstract={This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="http, hyper, text, transfer, protocol", + doi="10.17487/RFC2310", + } + +@misc{rfc2311, + author="S. Dusse and P. Hoffman and B. Ramsdell and L. Lundblade and L. Repka", + title="{S/MIME Version 2 Message Specification}", + howpublished="RFC 2311 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2311", + pages="1--37", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2311.txt", + key="RFC 2311", + abstract={This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="SMIME-MSG, secure, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2311", + } + +@misc{rfc2312, + author="S. Dusse and P. Hoffman and B. Ramsdell and J. Weinstein", + title="{S/MIME Version 2 Certificate Handling}", + howpublished="RFC 2312 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2312", + pages="1--20", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2312.txt", + key="RFC 2312", + abstract={This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="SMIME-CERT, secure, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2312", + } + +@misc{rfc2313, + author="B. Kaliski", + title="{PKCS \#1: RSA Encryption Version 1.5}", + howpublished="RFC 2313 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2313", + pages="1--19", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2437", +url="https://www.rfc-editor.org/rfc/rfc2313.txt", + key="RFC 2313", + abstract={This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="PKCS-1, data, public, key, cryptosystem", + doi="10.17487/RFC2313", + } + +@misc{rfc2314, + author="B. Kaliski", + title="{PKCS \#10: Certification Request Syntax Version 1.5}", + howpublished="RFC 2314 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2314", + pages="1--8", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2986", +url="https://www.rfc-editor.org/rfc/rfc2314.txt", + key="RFC 2314", + abstract={This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="PKCS-10, public, key, distinguished, name, encryption, data", + doi="10.17487/RFC2314", + } + +@misc{rfc2315, + author="B. Kaliski", + title="{PKCS \#7: Cryptographic Message Syntax Version 1.5}", + howpublished="RFC 2315 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2315", + pages="1--32", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2315.txt", + key="RFC 2315", + abstract={This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="PKCS-7, data, authentication, PEM, privacy, enhanced, mail", + doi="10.17487/RFC2315", + } + +@misc{rfc2316, + author="S. Bellovin", + title="{Report of the IAB Security Architecture Workshop}", + howpublished="RFC 2316 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2316", + pages="1--9", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2316.txt", + key="RFC 2316", + abstract={On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="Internet, Board, protocols, tools", + doi="10.17487/RFC2316", + } + +@misc{rfc2317, + author="H. Eidnes and G. de Groot and P. Vixie", + title="{Classless IN-ADDR.ARPA delegation}", + howpublished="RFC 2317 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2317", + pages="1--10", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2317.txt", + key="RFC 2317", + abstract={This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="routing, mapping, addresses, zone, files", + doi="10.17487/RFC2317", + } + +@misc{rfc2318, + author="H. Lie and B. Bos and C. Lilley", + title="{The text/css Media Type}", + howpublished="RFC 2318 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2318", + pages="1--5", + year=1998, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2318.txt", + key="RFC 2318", + abstract={This memo provides information about the text/css Media Type. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="TEXT-CSS, MIME, multipurpose, Internet, mail, extension", + doi="10.17487/RFC2318", + } + +@misc{rfc2319, + author="KOI8-U Working Group", + title="{Ukrainian Character Set KOI8-U}", + howpublished="RFC 2319 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2319", + pages="1--9", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2319.txt", + key="RFC 2319", + abstract={This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="KOI8-U, encoding, mail, information, resources", + doi="10.17487/RFC2319", + } + +@misc{rfc2320, + author="M. Greene and J. Luciani and K. White and T. Kuo", + title="{Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)}", + howpublished="RFC 2320 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2320", + pages="1--52", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2320.txt", + key="RFC 2320", + abstract={The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM. [STANDARDS-TRACK]}, + keywords="IPOA-MIB, management, information, base, internet, protocol, address, resolution, asynchronous, transfer, mode", + doi="10.17487/RFC2320", + } + +@misc{rfc2321, + author="A. Bressen", + title="{RITA -- The Reliable Internetwork Troubleshooting Agent}", + howpublished="RFC 2321 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2321", + pages="1--6", + year=1998, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2321.txt", + key="RFC 2321", + abstract={A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="networking, environments", + doi="10.17487/RFC2321", + } + +@misc{rfc2322, + author="K. van den Hout and A. Koopal and R. van Mook", + title="{Management of IP numbers by peg-dhcp}", + howpublished="RFC 2322 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2322", + pages="1--7", + year=1998, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2322.txt", + key="RFC 2322", + abstract={This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="Internet, Protocol, HIP, Hacking, in, progress", + doi="10.17487/RFC2322", + } + +@misc{rfc2323, + author="A. Ramos", + title="{IETF Identification and Security Guidelines}", + howpublished="RFC 2323 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2323", + pages="1--5", + year=1998, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2323.txt", + key="RFC 2323", + abstract={This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: ``facial hairius extremis''. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="facial, hairius, extremis, FHE", + doi="10.17487/RFC2323", + } + +@misc{rfc2324, + author="L. Masinter", + title="{Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)}", + howpublished="RFC 2324 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2324", + pages="1--10", + year=1998, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7168", +url="https://www.rfc-editor.org/rfc/rfc2324.txt", + key="RFC 2324", + abstract={This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="controlling, monitoring, diagnosing", + doi="10.17487/RFC2324", + } + +@misc{rfc2325, + author="M. Slavitch", + title="{Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2}", + howpublished="RFC 2325 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2325", + pages="1--8", + year=1998, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2325.txt", + key="RFC 2325", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="MIB, management, information, base, coffee, brewing", + doi="10.17487/RFC2325", + } + +@misc{rfc2326, + author="H. Schulzrinne and A. Rao and R. Lanphier", + title="{Real Time Streaming Protocol (RTSP)}", + howpublished="RFC 2326 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2326", + pages="1--92", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7826", +url="https://www.rfc-editor.org/rfc/rfc2326.txt", + key="RFC 2326", + abstract={The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. [STANDARDS-TRACK]}, + keywords="RTSP, audio, video, data, delivery, application, level,", + doi="10.17487/RFC2326", + } + +@misc{rfc2327, + author="M. Handley and V. Jacobson", + title="{SDP: Session Description Protocol}", + howpublished="RFC 2327 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2327", + pages="1--42", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4566, updated by RFC 3266", +url="https://www.rfc-editor.org/rfc/rfc2327.txt", + key="RFC 2327", + abstract={This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]}, + keywords="SDP, mbone, internet, multicast, backbone, multimedia", + doi="10.17487/RFC2327", + } + +@misc{rfc2328, + author="J. Moy", + title="{OSPF Version 2}", + howpublished="RFC 2328 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2328", + pages="1--244", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5709, 6549, 6845, 6860, 7474, 8042", +url="https://www.rfc-editor.org/rfc/rfc2328.txt", + key="RFC 2328", + abstract={This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]}, + keywords="OSPF2, Open, Shortest, Path, First, routing, Autonomous, system, AS", + doi="10.17487/RFC2328", + } + +@misc{rfc2329, + author="J. Moy", + title="{OSPF Standardization Report}", + howpublished="RFC 2329 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2329", + pages="1--9", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2329.txt", + key="RFC 2329", + abstract={This memo documents how the requirements for advancing a routing protocol to Full Standard have been met for OSPFv2. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="open, shortest, path, first", + doi="10.17487/RFC2329", + } + +@misc{rfc2330, + author="V. Paxson and G. Almes and J. Mahdavi and M. Mathis", + title="{Framework for IP Performance Metrics}", + howpublished="RFC 2330 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2330", + pages="1--40", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7312", +url="https://www.rfc-editor.org/rfc/rfc2330.txt", + key="RFC 2330", + abstract={The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="Internet, Protocol, measurement, statistics", + doi="10.17487/RFC2330", + } + +@misc{rfc2331, + author="M. Maher", + title="{ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update}", + howpublished="RFC 2331 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2331", + pages="1--26", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2331.txt", + key="RFC 2331", + abstract={This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 to support IP over ATM environments as described in RFC 2225 and in RFC 2332. [STANDARDS-TRACK]}, + keywords="UNI-SIG, asynchronous, transfer, mode, internet, protocol", + doi="10.17487/RFC2331", + } + +@misc{rfc2332, + author="J. Luciani and D. Katz and D. Piscitello and B. Cole and N. Doraswamy", + title="{NBMA Next Hop Resolution Protocol (NHRP)}", + howpublished="RFC 2332 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2332", + pages="1--52", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2332.txt", + key="RFC 2332", + abstract={This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the ``NBMA next hop'' towards a destination station. [STANDARDS-TRACK]}, + keywords="NHRP, internetworking, layer, address, subnetwork, multiprotocol, non-broadcast, multiple, access", + doi="10.17487/RFC2332", + } + +@misc{rfc2333, + author="D. Cansever", + title="{NHRP Protocol Applicability Statement}", + howpublished="RFC 2333 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2333", + pages="1--9", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2333.txt", + key="RFC 2333", + abstract={As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK]}, + keywords="next, hop, resolution, protocol, routing, internet, protocol", + doi="10.17487/RFC2333", + } + +@misc{rfc2334, + author="J. Luciani and G. Armitage and J. Halpern and N. Doraswamy", + title="{Server Cache Synchronization Protocol (SCSP)}", + howpublished="RFC 2334 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2334", + pages="1--40", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2334.txt", + key="RFC 2334", + abstract={This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. [STANDARDS-TRACK]}, + keywords="SCSP, cache, synchronization, replication, NBMA, non, broadcast, multiple, access", + doi="10.17487/RFC2334", + } + +@misc{rfc2335, + author="J. Luciani", + title="{A Distributed NHRP Service Using SCSP}", + howpublished="RFC 2335 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2335", + pages="1--7", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2335.txt", + key="RFC 2335", + abstract={This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK]}, + keywords="NHRP-SCSP, next, hop, resolution, protocol, server, cache, sychronization, protocol", + doi="10.17487/RFC2335", + } + +@misc{rfc2336, + author="J. Luciani", + title="{Classical IP and ARP over ATM to NHRP Transition}", + howpublished="RFC 2336 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2336", + pages="1--5", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2336.txt", + key="RFC 2336", + abstract={This document describes methods and procedures for the graceful transition from an ATMARP LIS to an NHRP LIS network model over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2336", + } + +@misc{rfc2337, + author="D. Farinacci and D. Meyer and Y. Rekhter", + title="{Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM}", + howpublished="RFC 2337 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2337", + pages="1--8", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2337.txt", + key="RFC 2337", + abstract={This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="internet, protocol, asynchronous, transfer, mode", + doi="10.17487/RFC2337", + } + +@misc{rfc2338, + author="S. Knight and D. Weaver and D. Whipple and R. Hinden and D. Mitzel and P. Hunt and P. Higginson and M. Shand and A. Lindem", + title="{Virtual Router Redundancy Protocol}", + howpublished="RFC 2338 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2338", + pages="1--27", + year=1998, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3768", +url="https://www.rfc-editor.org/rfc/rfc2338.txt", + key="RFC 2338", + abstract={This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]}, + keywords="VRRP, vrrp, lan, local, area, network, ip, internet, protocol", + doi="10.17487/RFC2338", + } + +@misc{rfc2339, + author="The Internet Society and Sun Microsystems", + title="{An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols}", + howpublished="RFC 2339 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2339", + pages="1--5", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2339.txt", + key="RFC 2339", + abstract={This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="ISOC, network, file, system, internet, engineering, task, force", + doi="10.17487/RFC2339", + } + +@misc{rfc2340, + author="B. Jamoussi and D. Jamieson and D. Williston and S. Gabe", + title="{Nortel's Virtual Network Switching (VNS) Overview}", + howpublished="RFC 2340 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2340", + pages="1--14", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2340.txt", + key="RFC 2340", + abstract={This document provides an overview of Virtual Network Switching (VNS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="routing, packet, switching, multi-protocol", + doi="10.17487/RFC2340", + } + +@misc{rfc2341, + author="A. Valencia and M. Littlewood and T. Kolar", + title="{Cisco Layer Two Forwarding (Protocol) ``L2F''}", + howpublished="RFC 2341 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2341", + pages="1--29", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2341.txt", + key="RFC 2341", + abstract={This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="L2F, tunneling, dial-up, network", + doi="10.17487/RFC2341", + } + +@misc{rfc2342, + author="M. Gahrns and C. Newman", + title="{IMAP4 Namespace}", + howpublished="RFC 2342 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2342", + pages="1--10", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4466", +url="https://www.rfc-editor.org/rfc/rfc2342.txt", + key="RFC 2342", + abstract={This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]}, + keywords="IMAP4NAME, internet, message, access, protocol, mailbox", + doi="10.17487/RFC2342", + } + +@misc{rfc2343, + author="M. Civanlar and G. Cash and B. Haskell", + title="{RTP Payload Format for Bundled MPEG}", + howpublished="RFC 2343 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2343", + pages="1--8", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2343.txt", + key="RFC 2343", + abstract={This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="RTP-MPEG, real-time, transport, protocol, audio, video", + doi="10.17487/RFC2343", + } + +@misc{rfc2344, + author="G. {Montenegro (Ed.)}", + title="{Reverse Tunneling for Mobile IP}", + howpublished="RFC 2344 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2344", + pages="1--19", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3024", +url="https://www.rfc-editor.org/rfc/rfc2344.txt", + key="RFC 2344", + abstract={This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS-TRACK]}, + keywords="MOBILIPREV, internet, protocol, extensions, home, foreign, agent, encapsulating, delivery, style", + doi="10.17487/RFC2344", + } + +@misc{rfc2345, + author="J. Klensin and T. Wolf and G. Oglesby", + title="{Domain Names and Company Name Retrieval}", + howpublished="RFC 2345 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2345", + pages="1--14", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2345.txt", + key="RFC 2345", + abstract={This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="URL, mapping, service, whois, dns", + doi="10.17487/RFC2345", + } + +@misc{rfc2346, + author="J. Palme", + title="{Making Postscript and PDF International}", + howpublished="RFC 2346 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2346", + pages="1--6", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2346.txt", + key="RFC 2346", + abstract={Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world. North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="portable, document, format, document", + doi="10.17487/RFC2346", + } + +@misc{rfc2347, + author="G. Malkin and A. Harkin", + title="{TFTP Option Extension}", + howpublished="RFC 2347 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2347", + pages="1--7", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2347.txt", + key="RFC 2347", + abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. [STANDARDS-TRACK]}, + keywords="TFTP-Ext, trivial, file, transfer, booting, client, server", + doi="10.17487/RFC2347", + } + +@misc{rfc2348, + author="G. Malkin and A. Harkin", + title="{TFTP Blocksize Option}", + howpublished="RFC 2348 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2348", + pages="1--5", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2348.txt", + key="RFC 2348", + abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]}, + keywords="TFTP-Blk, trivial, file, transfer, booting, client, server, extension", + doi="10.17487/RFC2348", + } + +@misc{rfc2349, + author="G. Malkin and A. Harkin", + title="{TFTP Timeout Interval and Transfer Size Options}", + howpublished="RFC 2349 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2349", + pages="1--5", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2349.txt", + key="RFC 2349", + abstract={The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes two TFTP options. [STANDARDS-TRACK]}, + keywords="TFTP-Opt, trivial, file, transfer, booting, client, server, extension", + doi="10.17487/RFC2349", + } + +@misc{rfc2350, + author="N. Brownlee and E. Guttman", + title="{Expectations for Computer Security Incident Response}", + howpublished="RFC 2350 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2350", + pages="1--38", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2350.txt", + key="RFC 2350", + keywords="CSIRT, guidelines, user", + doi="10.17487/RFC2350", + } + +@misc{rfc2351, + author="A. Robert", + title="{Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP}", + howpublished="RFC 2351 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2351", + pages="1--23", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2351.txt", + key="RFC 2351", + abstract={This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords=", internet, protocol, encapsulation, transactional, traffic, messaging", + doi="10.17487/RFC2351", + } + +@misc{rfc2352, + author="O. Vaughan", + title="{A Convention For Using Legal Names as Domain Names}", + howpublished="RFC 2352 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2352", + pages="1--8", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2352.txt", + key="RFC 2352", + abstract={The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="DNS", + doi="10.17487/RFC2352", + } + +@misc{rfc2353, + author="G. Dudley", + title="{APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document}", + howpublished="RFC 2353 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2353", + pages="1--48", + year=1998, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2353.txt", + key="RFC 2353", + abstract={This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="internet, protocol, advanced, peer-to-peer, networking, high, performance, routing", + doi="10.17487/RFC2353", + } + +@misc{rfc2354, + author="C. Perkins and O. Hodson", + title="{Options for Repair of Streaming Media}", + howpublished="RFC 2354 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2354", + pages="1--12", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2354.txt", + key="RFC 2354", + abstract={This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="packets, UDP, user, datagram, protocol", + doi="10.17487/RFC2354", + } + +@misc{rfc2355, + author="B. Kelly", + title="{TN3270 Enhancements}", + howpublished="RFC 2355 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2355", + pages="1--38", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6270", +url="https://www.rfc-editor.org/rfc/rfc2355.txt", + key="RFC 2355", + abstract={This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK]}, + keywords="TN3270E, Telnet, option, client", + doi="10.17487/RFC2355", + } + +@misc{rfc2356, + author="G. Montenegro and V. Gupta", + title="{Sun's SKIP Firewall Traversal for Mobile IP}", + howpublished="RFC 2356 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2356", + pages="1--24", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2356.txt", + key="RFC 2356", + abstract={The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.}, + keywords="Internet, Protocol, security, traffic", + doi="10.17487/RFC2356", + } + +@misc{rfc2357, + author="A. Mankin and A. Romanow and S. Bradner and V. Paxson", + title="{IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols}", + howpublished="RFC 2357 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2357", + pages="1--11", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2357.txt", + key="RFC 2357", + abstract={This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="internet, engineering, task, force, rmtp, procedures", + doi="10.17487/RFC2357", + } + +@misc{rfc2358, + author="J. Flick and J. Johnson", + title="{Definitions of Managed Objects for the Ethernet-like Interface Types}", + howpublished="RFC 2358 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2358", + pages="1--39", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2665", +url="https://www.rfc-editor.org/rfc/rfc2358.txt", + key="RFC 2358", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 ``Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2''. This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK]}, + keywords="MIB, Management, Information, Base, 802.3", + doi="10.17487/RFC2358", + } + +@misc{rfc2359, + author="J. Myers", + title="{IMAP4 UIDPLUS extension}", + howpublished="RFC 2359 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2359", + pages="1--6", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4315", +url="https://www.rfc-editor.org/rfc/rfc2359.txt", + key="RFC 2359", + abstract={The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]}, + keywords="IMAP4UIDPL, internet, message, access, protocol, disconnected, operation", + doi="10.17487/RFC2359", + } + +@misc{rfc2360, + author="G. Scott", + title="{Guide for Internet Standards Writers}", + howpublished="RFC 2360 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2360", + pages="1--20", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2360.txt", + key="RFC 2360", + abstract={This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="specification, multiple, implementations", + doi="10.17487/RFC2360", + } + +@misc{rfc2361, + author="E. Fleischman", + title="{WAVE and AVI Codec Registries}", + howpublished="RFC 2361 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2361", + pages="1--71", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2361.txt", + key="RFC 2361", + abstract={The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="multimedia, parameter, audio, video, microsoft", + doi="10.17487/RFC2361", + } + +@misc{rfc2362, + author="D. Estrin and D. Farinacci and A. Helmy and D. Thaler and S. Deering and M. Handley and V. Jacobson and C. Liu and P. Sharma and L. Wei", + title="{Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification}", + howpublished="RFC 2362 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2362", + pages="1--66", + year=1998, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4601, 5059", +url="https://www.rfc-editor.org/rfc/rfc2362.txt", + key="RFC 2362", + abstract={This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.}, + keywords="PIM-SM], routing, message, type, timers, flags", + doi="10.17487/RFC2362", + } + +@misc{rfc2363, + author="G. Gross and M. Kaycee and A. Li and A. Malis and J. Stephens", + title="{PPP Over FUNI}", + howpublished="RFC 2363 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2363", + pages="1--12", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2363.txt", + key="RFC 2363", + abstract={This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="PPP-FUNI, point-to-point, protocol, atm, synchronous, transfer, mode, frame, user, network, interface", + doi="10.17487/RFC2363", + } + +@misc{rfc2364, + author="G. Gross and M. Kaycee and A. Li and A. Malis and J. Stephens", + title="{PPP Over AAL5}", + howpublished="RFC 2364 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2364", + pages="1--12", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2364.txt", + key="RFC 2364", + abstract={This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="PPP-AAL, point-to-point, protocol, link, control, network-layer, authentication, compression", + doi="10.17487/RFC2364", + } + +@misc{rfc2365, + author="D. Meyer", + title="{Administratively Scoped IP Multicast}", + howpublished="RFC 2365 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2365", + pages="1--8", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2365.txt", + key="RFC 2365", + abstract={This document defines the ``administratively scoped IPv4 multicast space'' to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, protocol, IPv4, ipv6, address, classes", + doi="10.17487/RFC2365", + } + +@misc{rfc2366, + author="C. Chung and M. Greene", + title="{Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks}", + howpublished="RFC 2366 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2366", + pages="1--76", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2417", +url="https://www.rfc-editor.org/rfc/rfc2366.txt", + key="RFC 2366", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks'. [STANDARDS-TRACK]}, + keywords="MIB, management, information, base, asynchronous, transfer, mode", + doi="10.17487/RFC2366", + } + +@misc{rfc2367, + author="D. McDonald and C. Metz and B. Phan", + title="{PF\_KEY Key Management API, Version 2}", + howpublished="RFC 2367 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2367", + pages="1--68", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2367.txt", + key="RFC 2367", + abstract={A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="IP, internet, protocol, security, application, programming, interface", + doi="10.17487/RFC2367", + } + +@misc{rfc2368, + author="P. Hoffman and L. Masinter and J. Zawinski", + title="{The mailto URL scheme}", + howpublished="RFC 2368 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2368", + pages="1--10", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6068", +url="https://www.rfc-editor.org/rfc/rfc2368.txt", + key="RFC 2368", + abstract={This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]}, + keywords="URLMAILTO, uniform, resource, locator, electronic, mail, addresses", + doi="10.17487/RFC2368", + } + +@misc{rfc2369, + author="G. Neufeld and J. Baer", + title="{The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields}", + howpublished="RFC 2369 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2369", + pages="1--15", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2369.txt", + key="RFC 2369", + abstract={The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK]}, + keywords="uniform, resource, locator, email, header, fields", + doi="10.17487/RFC2369", + } + +@misc{rfc2370, + author="R. Coltun", + title="{The OSPF Opaque LSA Option}", + howpublished="RFC 2370 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2370", + pages="1--15", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5250, updated by RFC 3630", +url="https://www.rfc-editor.org/rfc/rfc2370.txt", + key="RFC 2370", + abstract={This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]}, + keywords="OSPF-LSA], open shortest path first, link state advertisement", + doi="10.17487/RFC2370", + } + +@misc{rfc2371, + author="J. Lyon and K. Evans and J. Klein", + title="{Transaction Internet Protocol Version 3.0}", + howpublished="RFC 2371 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2371", + pages="1--31", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2371.txt", + key="RFC 2371", + abstract={In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. [STANDARDS-TRACK]}, + keywords="TIPV3, TIP, commit, protocol, electronic, commerce", + doi="10.17487/RFC2371", + } + +@misc{rfc2372, + author="K. Evans and J. Klein and J. Lyon", + title="{Transaction Internet Protocol - Requirements and Supplemental Information}", + howpublished="RFC 2372 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2372", + pages="1--24", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2372.txt", + key="RFC 2372", + abstract={This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="TIP, commit, protocol, electronic, commerce", + doi="10.17487/RFC2372", + } + +@misc{rfc2373, + author="R. Hinden and S. Deering", + title="{IP Version 6 Addressing Architecture}", + howpublished="RFC 2373 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2373", + pages="1--26", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3513", +url="https://www.rfc-editor.org/rfc/rfc2373.txt", + key="RFC 2373", + abstract={This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]}, + keywords="internet, protocol, unicast, anycast, multicast, node", + doi="10.17487/RFC2373", + } + +@misc{rfc2374, + author="R. Hinden and M. O'Dell and S. Deering", + title="{An IPv6 Aggregatable Global Unicast Address Format}", + howpublished="RFC 2374 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2374", + pages="1--12", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3587", +url="https://www.rfc-editor.org/rfc/rfc2374.txt", + key="RFC 2374", + abstract={This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]}, + keywords="internet, protocol, architecture, routing", + doi="10.17487/RFC2374", + } + +@misc{rfc2375, + author="R. Hinden and S. Deering", + title="{IPv6 Multicast Address Assignments}", + howpublished="RFC 2375 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2375", + pages="1--8", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2375.txt", + key="RFC 2375", + abstract={This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="internet, protocol, multicast, scope, value", + doi="10.17487/RFC2375", + } + +@misc{rfc2376, + author="E. Whitehead and M. Murata", + title="{XML Media Types}", + howpublished="RFC 2376 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2376", + pages="1--15", + year=1998, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3023", +url="https://www.rfc-editor.org/rfc/rfc2376.txt", + key="RFC 2376", + abstract={This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="extensible, markup, language, web, authority, hypertext, transfer, protocol", + doi="10.17487/RFC2376", + } + +@misc{rfc2377, + author="A. Grimstad and R. Huber and S. Sataluri and M. Wahl", + title="{Naming Plan for Internet Directory-Enabled Applications}", + howpublished="RFC 2377 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2377", + pages="1--18", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4519", +url="https://www.rfc-editor.org/rfc/rfc2377.txt", + key="RFC 2377", + abstract={Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="x.500, applications, iwps, white, pages, service", + doi="10.17487/RFC2377", + } + +@misc{rfc2378, + author="R. Hedberg and P. Pomes", + title="{The CCSO Nameserver (Ph) Architecture}", + howpublished="RFC 2378 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2378", + pages="1--22", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2378.txt", + key="RFC 2378", + abstract={The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="computing, communications, services, office, database", + doi="10.17487/RFC2378", + } + +@misc{rfc2379, + author="L. Berger", + title="{RSVP over ATM Implementation Guidelines}", + howpublished="RFC 2379 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2379", + pages="1--8", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2379.txt", + key="RFC 2379", + abstract={This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="asynchronous, transfer, mode, resource, reservation, protocol, switched, circuits", + doi="10.17487/RFC2379", + } + +@misc{rfc2380, + author="L. Berger", + title="{RSVP over ATM Implementation Requirements}", + howpublished="RFC 2380 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2380", + pages="1--14", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2380.txt", + key="RFC 2380", + abstract={This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, asynchronous, transfer, mode, switched, circuits", + doi="10.17487/RFC2380", + } + +@misc{rfc2381, + author="M. Garrett and M. Borden", + title="{Interoperation of Controlled-Load Service and Guaranteed Service with ATM}", + howpublished="RFC 2381 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2381", + pages="1--43", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2381.txt", + key="RFC 2381", + abstract={This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK]}, + keywords="asynchronous, transfer, mode, mapping, traffic, parameters", + doi="10.17487/RFC2381", + } + +@misc{rfc2382, + author="E. {Crawley (Ed.)} and L. Berger and S. Berson and F. Baker and M. Borden and J. Krawczyk", + title="{A Framework for Integrated Services and RSVP over ATM}", + howpublished="RFC 2382 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2382", + pages="1--30", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2382.txt", + key="RFC 2382", + abstract={This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + doi="10.17487/RFC2382", + } + +@misc{rfc2383, + author="M. Suzuki", + title="{ST2+ over ATM Protocol Specification - UNI 3.1 Version}", + howpublished="RFC 2383 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2383", + pages="1--50", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2383.txt", + key="RFC 2383", + abstract={This document specifies an ATM-based protocol for communication between ST2+ agents. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="asynchronous, transfer, mode, stream, resource, reservation", + doi="10.17487/RFC2383", + } + +@misc{rfc2384, + author="R. Gellens", + title="{POP URL Scheme}", + howpublished="RFC 2384 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2384", + pages="1--8", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2384.txt", + key="RFC 2384", + abstract={This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]}, + keywords="POP-URL, post, office, protocol, uniform, resource, identifier, string, encapsulation", + doi="10.17487/RFC2384", + } + +@misc{rfc2385, + author="A. Heffernan", + title="{Protection of BGP Sessions via the TCP MD5 Signature Option}", + howpublished="RFC 2385 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2385", + pages="1--6", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5925, updated by RFC 6691", +url="https://www.rfc-editor.org/rfc/rfc2385.txt", + key="RFC 2385", + abstract={This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]}, + keywords="border, gateway, protocol, transmission, control, message, digest, algorithm", + doi="10.17487/RFC2385", + } + +@misc{rfc2386, + author="E. Crawley and R. Nair and B. Rajagopalan and H. Sandick", + title="{A Framework for QoS-based Routing in the Internet}", + howpublished="RFC 2386 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2386", + pages="1--37", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2386.txt", + key="RFC 2386", + abstract={This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="quality of service, interdomain, intradomain", + doi="10.17487/RFC2386", + } + +@misc{rfc2387, + author="E. Levinson", + title="{The MIME Multipart/Related Content-type}", + howpublished="RFC 2387 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2387", + pages="1--10", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2387.txt", + key="RFC 2387", + abstract={This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]}, + keywords="MIME-RELAT, multipurpose, internet, mail, extensions, body, parts, media-type", + doi="10.17487/RFC2387", + } + +@misc{rfc2388, + author="L. Masinter", + title="{Returning Values from Forms: multipart/form-data}", + howpublished="RFC 2388 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2388", + pages="1--9", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7578", +url="https://www.rfc-editor.org/rfc/rfc2388.txt", + key="RFC 2388", + abstract={This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]}, + keywords="media-type, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2388", + } + +@misc{rfc2389, + author="P. Hethmon and R. Elz", + title="{Feature negotiation mechanism for the File Transfer Protocol}", + howpublished="RFC 2389 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2389", + pages="1--9", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2389.txt", + key="RFC 2389", + abstract={This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. [STANDARDS-TRACK]}, + keywords="FTP, catalogue", + doi="10.17487/RFC2389", + } + +@misc{rfc2390, + author="T. Bradley and C. Brown and A. Malis", + title="{Inverse Address Resolution Protocol}", + howpublished="RFC 2390 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2390", + pages="1--10", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2390.txt", + key="RFC 2390", + abstract={This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]}, + keywords="IARP, iarp, hardware, frame, relay", + doi="10.17487/RFC2390", + } + +@misc{rfc2391, + author="P. Srisuresh and D. Gan", + title="{Load Sharing using IP Network Address Translation (LSNAT)}", + howpublished="RFC 2391 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2391", + pages="1--18", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2391.txt", + key="RFC 2391", + abstract={In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="internet, protocol, datagram, server", + doi="10.17487/RFC2391", + } + +@misc{rfc2392, + author="E. Levinson", + title="{Content-ID and Message-ID Uniform Resource Locators}", + howpublished="RFC 2392 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2392", + pages="1--6", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2392.txt", + key="RFC 2392", + abstract={The Uniform Resource Locator (URL) schemes, ``cid:'' and ``mid:'' allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]}, + keywords="CIDMID-URL, Hyper, Text, Markup, Language, URL, MIME", + doi="10.17487/RFC2392", + } + +@misc{rfc2393, + author="A. Shacham and R. Monsour and R. Pereira and M. Thomas", + title="{IP Payload Compression Protocol (IPComp)}", + howpublished="RFC 2393 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2393", + pages="1--10", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3173", +url="https://www.rfc-editor.org/rfc/rfc2393.txt", + key="RFC 2393", + abstract={This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]}, + keywords="IPCOMP, internet, protocol, datagram, lossless", + doi="10.17487/RFC2393", + } + +@misc{rfc2394, + author="R. Pereira", + title="{IP Payload Compression Using DEFLATE}", + howpublished="RFC 2394 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2394", + pages="1--6", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2394.txt", + key="RFC 2394", + abstract={This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="internet, protocol, algorithm, datagram, format", + doi="10.17487/RFC2394", + } + +@misc{rfc2395, + author="R. Friend and R. Monsour", + title="{IP Payload Compression Using LZS}", + howpublished="RFC 2395 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2395", + pages="1--9", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2395.txt", + key="RFC 2395", + abstract={This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="internet, protocol, algorithm, datagram, lossless", + doi="10.17487/RFC2395", + } + +@misc{rfc2396, + author="T. Berners-Lee and R. Fielding and L. Masinter", + title="{Uniform Resource Identifiers (URI): Generic Syntax}", + howpublished="RFC 2396 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2396", + pages="1--40", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3986, updated by RFC 2732", +url="https://www.rfc-editor.org/rfc/rfc2396.txt", + key="RFC 2396", + abstract={This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK]}, + keywords="URI-GEN, characters, string, absolute, relative", + doi="10.17487/RFC2396", + } + +@misc{rfc2397, + author="L. Masinter", + title="{The ``data'' URL scheme}", + howpublished="RFC 2397 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2397", + pages="1--5", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2397.txt", + key="RFC 2397", + abstract={A new URL scheme, ``data'', is defined. It allows inclusion of small data items as ``immediate'' data, as if it had been included externally. [STANDARDS-TRACK]}, + keywords="DATA-URL, uniform, resource, identifiers, media, type", + doi="10.17487/RFC2397", + } + +@misc{rfc2398, + author="S. Parker and C. Schmechel", + title="{Some Testing Tools for TCP Implementors}", + howpublished="RFC 2398 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2398", + pages="1--15", + year=1998, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2398.txt", + key="RFC 2398", + abstract={This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.}, + keywords="transmission, control, protocol, catalogue", + doi="10.17487/RFC2398", + } + +@misc{rfc2399, + author="A. Ramos", + title="{Request for Comments Summary}", + howpublished="RFC 2399 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2399", + pages="1--23", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2399.txt", + key="RFC 2399", + doi="10.17487/RFC2399", + } + +@misc{rfc2400, + author="J. Postel and J. Reynolds", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2400 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2400", + pages="1--47", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2500", +url="https://www.rfc-editor.org/rfc/rfc2400.txt", + key="RFC 2400", + abstract={This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC2400", + } + +@misc{rfc2401, + author="S. Kent and R. Atkinson", + title="{Security Architecture for the Internet Protocol}", + howpublished="RFC 2401 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2401", + pages="1--66", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4301, updated by RFC 3168", +url="https://www.rfc-editor.org/rfc/rfc2401.txt", + key="RFC 2401", + abstract={This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]}, + keywords="IPSEC, ipsec, authentication, encapsulation, IP, IPv4, IPv6, IP-layer", + doi="10.17487/RFC2401", + } + +@misc{rfc2402, + author="S. Kent and R. Atkinson", + title="{IP Authentication Header}", + howpublished="RFC 2402 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2402", + pages="1--22", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4302, 4305", +url="https://www.rfc-editor.org/rfc/rfc2402.txt", + key="RFC 2402", + abstract={The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just ``authentication''), and to provide protection against replays. [STANDARDS-TRACK]}, + keywords="IP-AUTH, ipsec, Internet, Protocol, AH, security, IPv4, IPv6", + doi="10.17487/RFC2402", + } + +@misc{rfc2403, + author="C. Madson and R. Glenn", + title="{The Use of HMAC-MD5-96 within ESP and AH}", + howpublished="RFC 2403 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2403", + pages="1--7", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2403.txt", + key="RFC 2403", + abstract={This memo describes the use of the HMAC algorithm in conjunction with the MD5 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]}, + keywords="ipsec, authentication, mechanism, header, security, architecture", + doi="10.17487/RFC2403", + } + +@misc{rfc2404, + author="C. Madson and R. Glenn", + title="{The Use of HMAC-SHA-1-96 within ESP and AH}", + howpublished="RFC 2404 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2404", + pages="1--7", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2404.txt", + key="RFC 2404", + abstract={This memo describes the use of the HMAC algorithm in conjunction with the SHA-1 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]}, + keywords="ipsec, authentication, mechanism, header, security, architecture, payload", + doi="10.17487/RFC2404", + } + +@misc{rfc2405, + author="C. Madson and N. Doraswamy", + title="{The ESP DES-CBC Cipher Algorithm With Explicit IV}", + howpublished="RFC 2405 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2405", + pages="1--10", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2405.txt", + key="RFC 2405", + abstract={This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]}, + keywords="ESPDES-CBC, ipsec, payload, security, architecture, encryption", + doi="10.17487/RFC2405", + } + +@misc{rfc2406, + author="S. Kent and R. Atkinson", + title="{IP Encapsulating Security Payload (ESP)}", + howpublished="RFC 2406 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2406", + pages="1--22", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4303, 4305", +url="https://www.rfc-editor.org/rfc/rfc2406.txt", + key="RFC 2406", + abstract={The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]}, + keywords="ESP, ipsec, internet, protocol, encapsulating, security, ipv4, ipv6", + doi="10.17487/RFC2406", + } + +@misc{rfc2407, + author="D. Piper", + title="{The Internet IP Security Domain of Interpretation for ISAKMP}", + howpublished="RFC 2407 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2407", + pages="1--32", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4306", +url="https://www.rfc-editor.org/rfc/rfc2407.txt", + key="RFC 2407", + abstract={This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]}, + keywords="ISAKMPSEC, ipsec, internet, protocol, security, association, key, management", + doi="10.17487/RFC2407", + } + +@misc{rfc2408, + author="D. Maughan and M. Schertler and M. Schneider and J. Turner", + title="{Internet Security Association and Key Management Protocol (ISAKMP)}", + howpublished="RFC 2408 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2408", + pages="1--86", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4306", +url="https://www.rfc-editor.org/rfc/rfc2408.txt", + key="RFC 2408", + abstract={This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK]}, + keywords="ISAKMP, ipsec, cryptography, authentication", + doi="10.17487/RFC2408", + } + +@misc{rfc2409, + author="D. Harkins and D. Carrel", + title="{The Internet Key Exchange (IKE)}", + howpublished="RFC 2409 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2409", + pages="1--41", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4306, updated by RFC 4109", +url="https://www.rfc-editor.org/rfc/rfc2409.txt", + key="RFC 2409", + abstract={This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]}, + keywords="IKE, ipsec, oakley, authentication, isakmp, internet, security, key, management", + doi="10.17487/RFC2409", + } + +@misc{rfc2410, + author="R. Glenn and S. Kent", + title="{The NULL Encryption Algorithm and Its Use With IPsec}", + howpublished="RFC 2410 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2410", + pages="1--6", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2410.txt", + key="RFC 2410", + abstract={This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]}, + keywords="ipsec, internet, protocol, security, esp, encapsulating, payload", + doi="10.17487/RFC2410", + } + +@misc{rfc2411, + author="R. Thayer and N. Doraswamy and R. Glenn", + title="{IP Security Document Roadmap}", + howpublished="RFC 2411 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2411", + pages="1--11", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6071", +url="https://www.rfc-editor.org/rfc/rfc2411.txt", + key="RFC 2411", + abstract={This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol. This memo provides information for the Internet community.}, + keywords="ipsec, internet, protocol, privacy, authentication", + doi="10.17487/RFC2411", + } + +@misc{rfc2412, + author="H. Orman", + title="{The OAKLEY Key Determination Protocol}", + howpublished="RFC 2412 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2412", + pages="1--55", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2412.txt", + key="RFC 2412", + abstract={This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This memo provides information for the Internet community.}, + keywords="ipsec, authentication, crytographic, secure, scalable", + doi="10.17487/RFC2412", + } + +@misc{rfc2413, + author="S. Weibel and J. Kunze and C. Lagoze and M. Wolf", + title="{Dublin Core Metadata for Resource Discovery}", + howpublished="RFC 2413 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2413", + pages="1--8", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5013", +url="https://www.rfc-editor.org/rfc/rfc2413.txt", + key="RFC 2413", + abstract={This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community.}, + keywords="workshop, electronic, librarians, network", + doi="10.17487/RFC2413", + } + +@misc{rfc2414, + author="M. Allman and S. Floyd and C. Partridge", + title="{Increasing TCP's Initial Window}", + howpublished="RFC 2414 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2414", + pages="1--14", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3390", +url="https://www.rfc-editor.org/rfc/rfc2414.txt", + key="RFC 2414", + abstract={This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TCP-WIN, transmission, control, protocol", + doi="10.17487/RFC2414", + } + +@misc{rfc2415, + author="K. Poduri and K. Nichols", + title="{Simulation Studies of Increased Initial TCP Window Size}", + howpublished="RFC 2415 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2415", + pages="1--11", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2415.txt", + key="RFC 2415", + abstract={This document covers some simulation studies of the effects of increasing the initial window size of TCP. This memo provides information for the Internet community.}, + keywords="transmission, control, protocol, file, transfer", + doi="10.17487/RFC2415", + } + +@misc{rfc2416, + author="T. Shepard and C. Partridge", + title="{When TCP Starts Up With Four Packets Into Only Three Buffers}", + howpublished="RFC 2416 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2416", + pages="1--7", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2416.txt", + key="RFC 2416", + abstract={This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet). This memo provides information for the Internet community.}, + keywords="transmission, control, protocol, performance", + doi="10.17487/RFC2416", + } + +@misc{rfc2417, + author="C. Chung and M. Greene", + title="{Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks}", + howpublished="RFC 2417 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2417", + pages="1--76", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2417.txt", + key="RFC 2417", + abstract={This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. [STANDARDS-TRACK]}, + keywords="MIB, management, information, base, asynchronous, transfer, mode", + doi="10.17487/RFC2417", + } + +@misc{rfc2418, + author="S. Bradner", + title="{IETF Working Group Guidelines and Procedures}", + howpublished="RFC 2418 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2418", + pages="1--26", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3934, 7475, 7776", +url="https://www.rfc-editor.org/rfc/rfc2418.txt", + key="RFC 2418", + abstract={This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="BCP, WG, escape, clause, procedures", + doi="10.17487/RFC2418", + } + +@misc{rfc2419, + author="K. Sklower and G. Meyer", + title="{The PPP DES Encryption Protocol, Version 2 (DESE-bis)}", + howpublished="RFC 2419 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2419", + pages="1--12", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2419.txt", + key="RFC 2419", + abstract={This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="DESE-bis, point-to-point, protocol, ecp, control", + doi="10.17487/RFC2419", + } + +@misc{rfc2420, + author="H. Kummert", + title="{The PPP Triple-DES Encryption Protocol (3DESE)}", + howpublished="RFC 2420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2420", + pages="1--8", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2420.txt", + key="RFC 2420", + abstract={This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS-TRACK]}, + keywords="3DESE, point-to-point, protocol, ecp, control", + doi="10.17487/RFC2420", + } + +@misc{rfc2421, + author="G. Vaudreuil and G. Parsons", + title="{Voice Profile for Internet Mail - version 2}", + howpublished="RFC 2421 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2421", + pages="1--56", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3801", +url="https://www.rfc-editor.org/rfc/rfc2421.txt", + key="RFC 2421", + abstract={This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]}, + keywords="MIME-VP2, vpim, messaging", + doi="10.17487/RFC2421", + } + +@misc{rfc2422, + author="G. Vaudreuil and G. Parsons", + title="{Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration}", + howpublished="RFC 2422 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2422", + pages="1--6", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3802", +url="https://www.rfc-editor.org/rfc/rfc2422.txt", + key="RFC 2422", + abstract={This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]}, + keywords="MIME-ADPCM, multipurpose, internet, mail, extensions, audio", + doi="10.17487/RFC2422", + } + +@misc{rfc2423, + author="G. Vaudreuil and G. Parsons", + title="{VPIM Voice Message MIME Sub-type Registration}", + howpublished="RFC 2423 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2423", + pages="1--6", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3801", +url="https://www.rfc-editor.org/rfc/rfc2423.txt", + key="RFC 2423", + abstract={This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]}, + keywords="MIME-VPIM, multipurpose, internet, mail, extensions, profiles", + doi="10.17487/RFC2423", + } + +@misc{rfc2424, + author="G. Vaudreuil and G. Parsons", + title="{Content Duration MIME Header Definition}", + howpublished="RFC 2424 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2424", + pages="1--4", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3803", +url="https://www.rfc-editor.org/rfc/rfc2424.txt", + key="RFC 2424", + abstract={This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]}, + keywords="CONT-DUR, multipurpose, internet, mail, extensions, time, media", + doi="10.17487/RFC2424", + } + +@misc{rfc2425, + author="T. Howes and M. Smith and F. Dawson", + title="{A MIME Content-Type for Directory Information}", + howpublished="RFC 2425 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2425", + pages="1--33", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6350", +url="https://www.rfc-editor.org/rfc/rfc2425.txt", + key="RFC 2425", + abstract={This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]}, + keywords="TXT-DIR, multipurpose, internet, mail, extensions, profiles", + doi="10.17487/RFC2425", + } + +@misc{rfc2426, + author="F. Dawson and T. Howes", + title="{vCard MIME Directory Profile}", + howpublished="RFC 2426 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2426", + pages="1--42", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6350", +url="https://www.rfc-editor.org/rfc/rfc2426.txt", + key="RFC 2426", + abstract={This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]}, + keywords="MIME-VCARD, multipurpose, internet, mail, extensions, white-pages, electronic, business, card", + doi="10.17487/RFC2426", + } + +@misc{rfc2427, + author="C. Brown and A. Malis", + title="{Multiprotocol Interconnect over Frame Relay}", + howpublished="RFC 2427 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2427", + pages="1--34", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2427.txt", + key="RFC 2427", + abstract={This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]}, + keywords="IP-FR, standard, standards, IP, over", + doi="10.17487/RFC2427", + } + +@misc{rfc2428, + author="M. Allman and S. Ostermann and C. Metz", + title="{FTP Extensions for IPv6 and NATs}", + howpublished="RFC 2428 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2428", + pages="1--8", + year=1998, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2428.txt", + key="RFC 2428", + abstract={This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK]}, + keywords="file, transfer, protocol, internet, network, address, translators", + doi="10.17487/RFC2428", + } + +@misc{rfc2429, + author="C. Bormann and L. Cline and G. Deisher and T. Gardos and C. Maciocco and D. Newell and J. Ott and G. Sullivan and S. Wenger and C. Zhu", + title="{RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)}", + howpublished="RFC 2429 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2429", + pages="1--17", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4629", +url="https://www.rfc-editor.org/rfc/rfc2429.txt", + key="RFC 2429", + abstract={This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]}, + keywords="real, time, transport, protocol, multicast, unicast", + doi="10.17487/RFC2429", + } + +@misc{rfc2430, + author="T. Li and Y. Rekhter", + title="{A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)}", + howpublished="RFC 2430 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2430", + pages="1--16", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2430.txt", + key="RFC 2430", + abstract={This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.}, + keywords="isp, internet, service, provider, packet, flow, multiprotocol, label, switching, mpls, resource, reservation, protocol, rsvp", + doi="10.17487/RFC2430", + } + +@misc{rfc2431, + author="D. Tynan", + title="{RTP Payload Format for BT.656 Video Encoding}", + howpublished="RFC 2431 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2431", + pages="1--10", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2431.txt", + key="RFC 2431", + abstract={This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]}, + keywords="real, time, transport, protocol, itu, multicast, unicast", + doi="10.17487/RFC2431", + } + +@misc{rfc2432, + author="K. Dubray", + title="{Terminology for IP Multicast Benchmarking}", + howpublished="RFC 2432 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2432", + pages="1--16", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2432.txt", + key="RFC 2432", + abstract={The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. This memo provides information for the Internet community.}, + keywords="internet, protocol, network, forwarding, devices", + doi="10.17487/RFC2432", + } + +@misc{rfc2433, + author="G. Zorn and S. Cobb", + title="{Microsoft PPP CHAP Extensions}", + howpublished="RFC 2433 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2433", + pages="1--20", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2433.txt", + key="RFC 2433", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community.}, + keywords="point to point, protocol, challenge, handshake, authentication", + doi="10.17487/RFC2433", + } + +@misc{rfc2434, + author="T. Narten and H. Alvestrand", + title="{Guidelines for Writing an IANA Considerations Section in RFCs}", + howpublished="RFC 2434 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2434", + pages="1--11", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5226, updated by RFC 3692", +url="https://www.rfc-editor.org/rfc/rfc2434.txt", + key="RFC 2434", + abstract={This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, assigned, numbers, authority, values, implementations", + doi="10.17487/RFC2434", + } + +@misc{rfc2435, + author="L. Berc and W. Fenner and R. Frederick and S. McCanne and P. Stewart", + title="{RTP Payload Format for JPEG-compressed Video}", + howpublished="RFC 2435 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2435", + pages="1--27", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2435.txt", + key="RFC 2435", + abstract={This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK]}, + keywords="Real, Time, Transport, Protocol, Joint, Photographic, Experts, Group", + doi="10.17487/RFC2435", + } + +@misc{rfc2436, + author="R. Brett and S. Bradner and G. Parsons", + title="{Collaboration between ISOC/IETF and ITU-T}", + howpublished="RFC 2436 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2436", + pages="1--14", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3356", +url="https://www.rfc-editor.org/rfc/rfc2436.txt", + key="RFC 2436", + abstract={This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.}, + keywords="internet, society, engineering, task, force", + doi="10.17487/RFC2436", + } + +@misc{rfc2437, + author="B. Kaliski and J. Staddon", + title="{PKCS \#1: RSA Cryptography Specifications Version 2.0}", + howpublished="RFC 2437 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2437", + pages="1--39", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3447", +url="https://www.rfc-editor.org/rfc/rfc2437.txt", + key="RFC 2437", + abstract={This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.}, + keywords="data, public, key, cryptosystem", + doi="10.17487/RFC2437", + } + +@misc{rfc2438, + author="M. O'Dell and H. Alvestrand and B. Wijnen and S. Bradner", + title="{Advancement of MIB specifications on the IETF Standards Track}", + howpublished="RFC 2438 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2438", + pages="1--7", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2438.txt", + key="RFC 2438", + abstract={This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="management, information, base, internet, engineering, task, force", + doi="10.17487/RFC2438", + } + +@misc{rfc2439, + author="C. Villamizar and R. Chandra and R. Govindan", + title="{BGP Route Flap Damping}", + howpublished="RFC 2439 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2439", + pages="1--37", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2439.txt", + key="RFC 2439", + abstract={A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK]}, + keywords="Border, Gateway, Protocol, IDRP, Internet-Domain, Routing", + doi="10.17487/RFC2439", + } + +@misc{rfc2440, + author="J. Callas and L. Donnerhacke and H. Finney and R. Thayer", + title="{OpenPGP Message Format}", + howpublished="RFC 2440 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2440", + pages="1--65", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4880", +url="https://www.rfc-editor.org/rfc/rfc2440.txt", + key="RFC 2440", + abstract={This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]}, + keywords="pretty, good, privacy, encryption, authentication", + doi="10.17487/RFC2440", + } + +@misc{rfc2441, + author="D. Cohen", + title="{Working with Jon, Tribute delivered at UCLA, October 30, 1998}", + howpublished="RFC 2441 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2441", + pages="1--6", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2441.txt", + key="RFC 2441", + abstract={This memo provides information for the Internet community.}, + keywords="Jonathan B Postel", + doi="10.17487/RFC2441", + } + +@misc{rfc2442, + author="N. Freed and D. Newman and J. Belissent and M. Hoy", + title="{The Batch SMTP Media Type}", + howpublished="RFC 2442 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2442", + pages="1--9", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2442.txt", + key="RFC 2442", + abstract={This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport. This memo provides information for the Internet community}, + keywords="simple, transfer, protocol, mime, multipurpose, internet, mail, extensions, tunneling", + doi="10.17487/RFC2442", + } + +@misc{rfc2443, + author="J. Luciani and A. Gallo", + title="{A Distributed MARS Service Using SCSP}", + howpublished="RFC 2443 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2443", + pages="1--18", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2443.txt", + key="RFC 2443", + abstract={This document describes a method for distributing a MARS service within a LIS. This method uses the Server Cache Synchronization Protocol (SCSP) to synchronize the MARS Server databases within a LIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). [STANDARDS-TRACK]}, + keywords="MARS-SCSP, server, cache, syncronization, protocol, atm, asynchronous, transfer, mode", + doi="10.17487/RFC2443", + } + +@misc{rfc2444, + author="C. Newman", + title="{The One-Time-Password SASL Mechanism}", + howpublished="RFC 2444 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2444", + pages="1--7", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2444.txt", + key="RFC 2444", + abstract={OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK]}, + keywords="OTP-SASL, otp, simple, authentication, security, layer", + doi="10.17487/RFC2444", + } + +@misc{rfc2445, + author="F. Dawson and D. Stenerson", + title="{Internet Calendaring and Scheduling Core Object Specification (iCalendar)}", + howpublished="RFC 2445 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2445", + pages="1--148", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5545", +url="https://www.rfc-editor.org/rfc/rfc2445.txt", + key="RFC 2445", + abstract={This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]}, + keywords="ICALENDAR, internet, interoperable, mime, multipurpose, mail, extensions", + doi="10.17487/RFC2445", + } + +@misc{rfc2446, + author="S. Silverberg and S. Mansour and F. Dawson and R. Hopson", + title="{iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries}", + howpublished="RFC 2446 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2446", + pages="1--109", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5546", +url="https://www.rfc-editor.org/rfc/rfc2446.txt", + key="RFC 2446", + abstract={This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK]}, + keywords="ITIP, internet, systems, interoperability", + doi="10.17487/RFC2446", + } + +@misc{rfc2447, + author="F. Dawson and S. Mansour and S. Silverberg", + title="{iCalendar Message-Based Interoperability Protocol (iMIP)}", + howpublished="RFC 2447 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2447", + pages="1--18", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6047", +url="https://www.rfc-editor.org/rfc/rfc2447.txt", + key="RFC 2447", + abstract={This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]}, + keywords="IMIP, internet, electronic, mail, transport", + doi="10.17487/RFC2447", + } + +@misc{rfc2448, + author="M. Civanlar and G. Cash and B. Haskell", + title="{AT\&T's Error Resilient Video Transmission Technique}", + howpublished="RFC 2448 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2448", + pages="1--7", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2448.txt", + key="RFC 2448", + abstract={This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. This memo provides information for the Internet community.}, + keywords="packets, network, bitstreams", + doi="10.17487/RFC2448", + } + +@misc{rfc2449, + author="R. Gellens and C. Newman and L. Lundblade", + title="{POP3 Extension Mechanism}", + howpublished="RFC 2449 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2449", + pages="1--19", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5034", +url="https://www.rfc-editor.org/rfc/rfc2449.txt", + key="RFC 2449", + abstract={This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]}, + keywords="POP3-EXT, post, office, protocol, server", + doi="10.17487/RFC2449", + } + +@misc{rfc2450, + author="R. Hinden", + title="{Proposed TLA and NLA Assignment Rule}", + howpublished="RFC 2450 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2450", + pages="1--11", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2450.txt", + key="RFC 2450", + abstract={This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community.}, + keywords="top-level, aggregation, identifiers, next-level, ipv6, internet, protocols, addresses", + doi="10.17487/RFC2450", + } + +@misc{rfc2451, + author="R. Pereira and R. Adams", + title="{The ESP CBC-Mode Cipher Algorithms}", + howpublished="RFC 2451 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2451", + pages="1--14", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2451.txt", + key="RFC 2451", + abstract={This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. [STANDARDS-TRACK]}, + keywords="ipsec, encapsulating, security, payload", + doi="10.17487/RFC2451", + } + +@misc{rfc2452, + author="M. Daniele", + title="{IP Version 6 Management Information Base for the Transmission Control Protocol}", + howpublished="RFC 2452 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2452", + pages="1--10", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4022, 8096", +url="https://www.rfc-editor.org/rfc/rfc2452.txt", + key="RFC 2452", + abstract={This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). [STANDARDS-TRACK]}, + keywords="mib, internet, protocol, tcp, ipv6", + doi="10.17487/RFC2452", + } + +@misc{rfc2453, + author="G. Malkin", + title="{RIP Version 2}", + howpublished="RFC 2453 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2453", + pages="1--39", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4822", +url="https://www.rfc-editor.org/rfc/rfc2453.txt", + key="RFC 2453", + abstract={This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]}, + keywords="RIP2, RIP-2", + doi="10.17487/RFC2453", + } + +@misc{rfc2454, + author="M. Daniele", + title="{IP Version 6 Management Information Base for the User Datagram Protocol}", + howpublished="RFC 2454 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2454", + pages="1--9", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4113, 8096", +url="https://www.rfc-editor.org/rfc/rfc2454.txt", + key="RFC 2454", + abstract={This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). [STANDARDS-TRACK]}, + keywords="mib, internet, protocol, udp, ipv6", + doi="10.17487/RFC2454", + } + +@misc{rfc2455, + author="B. Clouston and B. Moore", + title="{Definitions of Managed Objects for APPN}", + howpublished="RFC 2455 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2455", + pages="1--140", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2455.txt", + key="RFC 2455", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]}, + keywords="APPN-MIB, mib, management, information, base, advanced, peer-to-peer, networking", + doi="10.17487/RFC2455", + } + +@misc{rfc2456, + author="B. Clouston and B. Moore", + title="{Definitions of Managed Objects for APPN TRAPS}", + howpublished="RFC 2456 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2456", + pages="1--21", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2456.txt", + key="RFC 2456", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK]}, + keywords="mib, management, information, base, advanced, peer-to-peer, networking", + doi="10.17487/RFC2456", + } + +@misc{rfc2457, + author="B. Clouston and B. Moore", + title="{Definitions of Managed Objects for Extended Border Node}", + howpublished="RFC 2457 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2457", + pages="1--28", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2457.txt", + key="RFC 2457", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. [STANDARDS-TRACK]}, + keywords="EBN-MIB, mib, management, information, base, ebn", + doi="10.17487/RFC2457", + } + +@misc{rfc2458, + author="H. Lu and M. Krishnaswamy and L. Conroy and S. Bellovin and F. Burg and A. DeSimone and K. Tewani and P. Davidson and H. Schulzrinne and K. Vishwanathan", + title="{Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations}", + howpublished="RFC 2458 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2458", + pages="1--60", + year=1998, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2458.txt", + key="RFC 2458", + abstract={This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. This memo provides information for the Internet community.}, + doi="10.17487/RFC2458", + } + +@misc{rfc2459, + author="R. Housley and W. Ford and W. Polk and D. Solo", + title="{Internet X.509 Public Key Infrastructure Certificate and CRL Profile}", + howpublished="RFC 2459 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2459", + pages="1--129", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3280", +url="https://www.rfc-editor.org/rfc/rfc2459.txt", + key="RFC 2459", + abstract={This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]}, + keywords="digital, signatures, encryption, authentication", + doi="10.17487/RFC2459", + } + +@misc{rfc2460, + author="S. Deering and R. Hinden", + title="{Internet Protocol, Version 6 (IPv6) Specification}", + howpublished="RFC 2460 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2460", + pages="1--39", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8200, updated by RFCs 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045, 7112", +url="https://www.rfc-editor.org/rfc/rfc2460.txt", + key="RFC 2460", + abstract={This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]}, + keywords="IPV6, internet, protocol, next, generation, ipng", + doi="10.17487/RFC2460", + } + +@misc{rfc2461, + author="T. Narten and E. Nordmark and W. Simpson", + title="{Neighbor Discovery for IP Version 6 (IPv6)}", + howpublished="RFC 2461 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2461", + pages="1--93", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4861, updated by RFC 4311", +url="https://www.rfc-editor.org/rfc/rfc2461.txt", + key="RFC 2461", + abstract={This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]}, + keywords="IPV6-ND, internet, protocol, link-layer", + doi="10.17487/RFC2461", + } + +@misc{rfc2462, + author="S. Thomson and T. Narten", + title="{IPv6 Stateless Address Autoconfiguration}", + howpublished="RFC 2462 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2462", + pages="1--25", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4862", +url="https://www.rfc-editor.org/rfc/rfc2462.txt", + key="RFC 2462", + abstract={This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]}, + keywords="IPV6-AUTO, internet, protocol, host, link-local", + doi="10.17487/RFC2462", + } + +@misc{rfc2463, + author="A. Conta and S. Deering", + title="{Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification}", + howpublished="RFC 2463 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2463", + pages="1--18", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4443", +url="https://www.rfc-editor.org/rfc/rfc2463.txt", + key="RFC 2463", + abstract={This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]}, + keywords="ICMPv6, internet, protocol, link-local, autoconfigured, addresses", + doi="10.17487/RFC2463", + } + +@misc{rfc2464, + author="M. Crawford", + title="{Transmission of IPv6 Packets over Ethernet Networks}", + howpublished="RFC 2464 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2464", + pages="1--7", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6085, 8064", +url="https://www.rfc-editor.org/rfc/rfc2464.txt", + key="RFC 2464", + abstract={This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]}, + keywords="internet, protocol, link-local, autoconfigured, addresses", + doi="10.17487/RFC2464", + } + +@misc{rfc2465, + author="D. Haskin and S. Onishi", + title="{Management Information Base for IP Version 6: Textual Conventions and General Group}", + howpublished="RFC 2465 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2465", + pages="1--38", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4293, 8096", +url="https://www.rfc-editor.org/rfc/rfc2465.txt", + key="RFC 2465", + abstract={This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. [STANDARDS-TRACK]}, + keywords="mib, internet, protocol, ipv6", + doi="10.17487/RFC2465", + } + +@misc{rfc2466, + author="D. Haskin and S. Onishi", + title="{Management Information Base for IP Version 6: ICMPv6 Group}", + howpublished="RFC 2466 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2466", + pages="1--16", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4293, 8096", +url="https://www.rfc-editor.org/rfc/rfc2466.txt", + key="RFC 2466", + abstract={This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. [STANDARDS-TRACK]}, + keywords="ICMPv6-MIB, mib, internet, protocol, ipv6", + doi="10.17487/RFC2466", + } + +@misc{rfc2467, + author="M. Crawford", + title="{Transmission of IPv6 Packets over FDDI Networks}", + howpublished="RFC 2467 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2467", + pages="1--9", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc2467.txt", + key="RFC 2467", + abstract={This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS-TRACK]}, + keywords="internet, protocol, link-local, addresses, autoconfiguration", + doi="10.17487/RFC2467", + } + +@misc{rfc2468, + author="V. Cerf", + title="{I REMEMBER IANA}", + howpublished="RFC 2468 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2468", + pages="1--4", + year=1998, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2468.txt", + key="RFC 2468", + abstract={A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.}, + keywords="jonathan b postel", + doi="10.17487/RFC2468", + } + +@misc{rfc2469, + author="T. Narten and C. Burton", + title="{A Caution On The Canonical Ordering Of Link-Layer Addresses}", + howpublished="RFC 2469 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2469", + pages="1--5", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2469.txt", + key="RFC 2469", + abstract={Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in ``canonical form''. Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required. This memo provides information for the Internet community.}, + keywords="address, resolution, protocol, data, fields", + doi="10.17487/RFC2469", + } + +@misc{rfc2470, + author="M. Crawford and T. Narten and S. Thomas", + title="{Transmission of IPv6 Packets over Token Ring Networks}", + howpublished="RFC 2470 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2470", + pages="1--11", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc2470.txt", + key="RFC 2470", + abstract={This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]}, + keywords="internet, protocol, frame, format, link-local, addresses", + doi="10.17487/RFC2470", + } + +@misc{rfc2471, + author="R. Hinden and R. Fink and J. Postel", + title="{IPv6 Testing Address Allocation}", + howpublished="RFC 2471 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2471", + pages="1--5", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3701", +url="https://www.rfc-editor.org/rfc/rfc2471.txt", + key="RFC 2471", + abstract={This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community.}, + keywords="internet, protocol, protocotype, software, architecture", + doi="10.17487/RFC2471", + } + +@misc{rfc2472, + author="D. Haskin and E. Allen", + title="{IP Version 6 over PPP}", + howpublished="RFC 2472 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2472", + pages="1--14", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5072, 5172", +url="https://www.rfc-editor.org/rfc/rfc2472.txt", + key="RFC 2472", + abstract={This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. [STANDARDS-TRACK]}, + keywords="IPv6-PPP, internet, protocol, point-to-point, ipv6", + doi="10.17487/RFC2472", + } + +@misc{rfc2473, + author="A. Conta and S. Deering", + title="{Generic Packet Tunneling in IPv6 Specification}", + howpublished="RFC 2473 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2473", + pages="1--36", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2473.txt", + key="RFC 2473", + abstract={This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]}, + keywords="internet, protocol, encapsulation", + doi="10.17487/RFC2473", + } + +@misc{rfc2474, + author="K. Nichols and S. Blake and F. Baker and D. Black", + title="{Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers}", + howpublished="RFC 2474 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2474", + pages="1--20", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3168, 3260, 8436", +url="https://www.rfc-editor.org/rfc/rfc2474.txt", + key="RFC 2474", + abstract={This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]}, + keywords="internet, protocol, network, nodes", + doi="10.17487/RFC2474", + } + +@misc{rfc2475, + author="S. Blake and D. Black and M. Carlson and E. Davies and Z. Wang and W. Weiss", + title="{An Architecture for Differentiated Services}", + howpublished="RFC 2475 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2475", + pages="1--36", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3260", +url="https://www.rfc-editor.org/rfc/rfc2475.txt", + key="RFC 2475", + abstract={This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.}, + keywords="DIFFSRV], scalability, IP, internet, protocol", + doi="10.17487/RFC2475", + } + +@misc{rfc2476, + author="R. Gellens and J. Klensin", + title="{Message Submission}", + howpublished="RFC 2476 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2476", + pages="1--15", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4409", +url="https://www.rfc-editor.org/rfc/rfc2476.txt", + key="RFC 2476", + abstract={This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]}, + keywords="smtp, simple, mail, transfer, protocol, user, agent", + doi="10.17487/RFC2476", + } + +@misc{rfc2477, + author="B. Aboba and G. Zorn", + title="{Criteria for Evaluating Roaming Protocols}", + howpublished="RFC 2477 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2477", + pages="1--12", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2477.txt", + key="RFC 2477", + abstract={This document describes requirements for the provisioning of ``roaming capability'' for dialup Internet users. ``Roaming capability'' is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community.}, + keywords="ISP, internet, service, providers, operations", + doi="10.17487/RFC2477", + } + +@misc{rfc2478, + author="E. Baize and D. Pinkas", + title="{The Simple and Protected GSS-API Negotiation Mechanism}", + howpublished="RFC 2478 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2478", + pages="1--18", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4178", +url="https://www.rfc-editor.org/rfc/rfc2478.txt", + key="RFC 2478", + abstract={This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS-TRACK]}, + keywords="generic, service, application, security, program, interface", + doi="10.17487/RFC2478", + } + +@misc{rfc2479, + author="C. Adams", + title="{Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)}", + howpublished="RFC 2479 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2479", + pages="1--70", + year=1998, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2479.txt", + key="RFC 2479", + abstract={The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated ``receivers'' of the data unit. This memo provides information for the Internet community.}, + keywords="data, unit, authentication", + doi="10.17487/RFC2479", + } + +@misc{rfc2480, + author="N. Freed", + title="{Gateways and MIME Security Multiparts}", + howpublished="RFC 2480 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2480", + pages="1--6", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2480.txt", + key="RFC 2480", + abstract={This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]}, + keywords="mutltipurpose, internet, mail, extensions", + doi="10.17487/RFC2480", + } + +@misc{rfc2481, + author="K. Ramakrishnan and S. Floyd", + title="{A Proposal to add Explicit Congestion Notification (ECN) to IP}", + howpublished="RFC 2481 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2481", + pages="1--25", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3168", +url="https://www.rfc-editor.org/rfc/rfc2481.txt", + key="RFC 2481", + abstract={This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community.}, + keywords="ECN-IP, internet, protocol, tcp, transmission, control, transport", + doi="10.17487/RFC2481", + } + +@misc{rfc2482, + author="K. Whistler and G. Adams", + title="{Language Tagging in Unicode Plain Text}", + howpublished="RFC 2482 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2482", + pages="1--14", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6082", +url="https://www.rfc-editor.org/rfc/rfc2482.txt", + key="RFC 2482", + abstract={This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.}, + keywords="characters, strings, ASCII", + doi="10.17487/RFC2482", + } + +@misc{rfc2483, + author="M. Mealling and R. Daniel", + title="{URI Resolution Services Necessary for URN Resolution}", + howpublished="RFC 2483 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2483", + pages="1--16", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2483.txt", + key="RFC 2483", + abstract={Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community.}, + keywords="uniform, resource, identifier, names, locators, characteristics", + doi="10.17487/RFC2483", + } + +@misc{rfc2484, + author="G. Zorn", + title="{PPP LCP Internationalization Configuration Option}", + howpublished="RFC 2484 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2484", + pages="1--5", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2484.txt", + key="RFC 2484", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]}, + keywords="point-to-point, protocol, link, control, authentication", + doi="10.17487/RFC2484", + } + +@misc{rfc2485, + author="S. Drach", + title="{DHCP Option for The Open Group's User Authentication Protocol}", + howpublished="RFC 2485 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2485", + pages="1--4", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2485.txt", + key="RFC 2485", + abstract={This document defines a DHCP option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, UAP", + doi="10.17487/RFC2485", + } + +@misc{rfc2486, + author="B. Aboba and M. Beadles", + title="{The Network Access Identifier}", + howpublished="RFC 2486 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2486", + pages="1--8", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4282", +url="https://www.rfc-editor.org/rfc/rfc2486.txt", + key="RFC 2486", + abstract={This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]}, + keywords="NAI, tunneling, roaming", + doi="10.17487/RFC2486", + } + +@misc{rfc2487, + author="P. Hoffman", + title="{SMTP Service Extension for Secure SMTP over TLS}", + howpublished="RFC 2487 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2487", + pages="1--8", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3207", +url="https://www.rfc-editor.org/rfc/rfc2487.txt", + key="RFC 2487", + abstract={This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]}, + keywords="simple, mail, transfer, protocol, transport, layer, security, ssl", + doi="10.17487/RFC2487", + } + +@misc{rfc2488, + author="M. Allman and D. Glover and L. Sanchez", + title="{Enhancing TCP Over Satellite Channels using Standard Mechanisms}", + howpublished="RFC 2488 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2488", + pages="1--19", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2488.txt", + key="RFC 2488", + abstract={The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="transmission, control, protocol, network", + doi="10.17487/RFC2488", + } + +@misc{rfc2489, + author="R. Droms", + title="{Procedure for Defining New DHCP Options}", + howpublished="RFC 2489 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2489", + pages="1--5", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2939", +url="https://www.rfc-editor.org/rfc/rfc2489.txt", + key="RFC 2489", + abstract={This document describes the procedure for defining new DHCP options. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="mutipurpose, internet, mail, extensions", + doi="10.17487/RFC2489", + } + +@misc{rfc2490, + author="M. Pullen and R. Malghan and L. Lavu and G. Duan and J. Ma and H. Nah", + title="{A Simulation Model for IP Multicast with RSVP}", + howpublished="RFC 2490 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2490", + pages="1--31", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2490.txt", + key="RFC 2490", + abstract={This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language. This memo provides information for the Internet community.}, + keywords="internet, protocol, resource, reservation, ipv4", + doi="10.17487/RFC2490", + } + +@misc{rfc2491, + author="G. Armitage and P. Schulter and M. Jork and G. Harter", + title="{IPv6 over Non-Broadcast Multiple Access (NBMA) networks}", + howpublished="RFC 2491 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2491", + pages="1--44", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc2491.txt", + key="RFC 2491", + abstract={This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]}, + keywords="IPv6-NBMA, internet, protocol, routing, host", + doi="10.17487/RFC2491", + } + +@misc{rfc2492, + author="G. Armitage and P. Schulter and M. Jork", + title="{IPv6 over ATM Networks}", + howpublished="RFC 2492 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2492", + pages="1--12", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc2492.txt", + key="RFC 2492", + abstract={This document is a companion to the ION working group's architecture document, ``IPv6 over Non Broadcast Multiple Access (NBMA) networks''. It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. [STANDARDS-TRACK]}, + keywords="IPv6ATMNET, internet, protocol, asynchronous, transfer, mode, host", + doi="10.17487/RFC2492", + } + +@misc{rfc2493, + author="K. {Tesink (Ed.)}", + title="{Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals}", + howpublished="RFC 2493 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2493", + pages="1--9", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3593", +url="https://www.rfc-editor.org/rfc/rfc2493.txt", + key="RFC 2493", + abstract={This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. [STANDARDS-TRACK]}, + keywords="management, information, base, data", + doi="10.17487/RFC2493", + } + +@misc{rfc2494, + author="D. {Fowler (Ed.)}", + title="{Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type}", + howpublished="RFC 2494 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2494", + pages="1--25", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2494.txt", + key="RFC 2494", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2494", + } + +@misc{rfc2495, + author="D. {Fowler (Ed.)}", + title="{Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types}", + howpublished="RFC 2495 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2495", + pages="1--75", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3895", +url="https://www.rfc-editor.org/rfc/rfc2495.txt", + key="RFC 2495", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2495", + } + +@misc{rfc2496, + author="D. {Fowler (Ed.)}", + title="{Definitions of Managed Object for the DS3/E3 Interface Type}", + howpublished="RFC 2496 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2496", + pages="1--60", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3896", +url="https://www.rfc-editor.org/rfc/rfc2496.txt", + key="RFC 2496", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS1/E1/DS2/E2 (RFC 2495), and the work in progress SONET/SDH Interface Types. [STANDARDS-TRACK]}, + keywords="DS3-E3-MIB, management, information, base", + doi="10.17487/RFC2496", + } + +@misc{rfc2497, + author="I. Souvatzis", + title="{Transmission of IPv6 Packets over ARCnet Networks}", + howpublished="RFC 2497 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2497", + pages="1--6", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc2497.txt", + key="RFC 2497", + abstract={This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]}, + keywords="internet, protocol, frame, format, link-local", + doi="10.17487/RFC2497", + } + +@misc{rfc2498, + author="J. Mahdavi and V. Paxson", + title="{IPPM Metrics for Measuring Connectivity}", + howpublished="RFC 2498 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2498", + pages="1--10", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2678", +url="https://www.rfc-editor.org/rfc/rfc2498.txt", + key="RFC 2498", + abstract={This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.}, + keywords="IPPM-MET, internet, protocol, performance, metrics", + doi="10.17487/RFC2498", + } + +@misc{rfc2499, + author="A. Ramos", + title="{Request for Comments Summary}", + howpublished="RFC 2499 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2499", + pages="1--22", + year=1999, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2499.txt", + key="RFC 2499", + doi="10.17487/RFC2499", + } + +@misc{rfc2500, + author="J. Reynolds and R. Braden", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2500 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2500", + pages="1--28", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2600", +url="https://www.rfc-editor.org/rfc/rfc2500.txt", + key="RFC 2500", + abstract={This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC2500", + } + +@misc{rfc2501, + author="S. Corson and J. Macker", + title="{Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations}", + howpublished="RFC 2501 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2501", + pages="1--12", + year=1999, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2501.txt", + key="RFC 2501", + abstract={This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. This memo provides information for the Internet community.}, + keywords="MANET, packet, network, hardwire, wireless", + doi="10.17487/RFC2501", + } + +@misc{rfc2502, + author="M. Pullen and M. Myjak and C. Bouwens", + title="{Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment}", + howpublished="RFC 2502 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2502", + pages="1--11", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2502.txt", + key="RFC 2502", + abstract={This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. This memo provides information for the Internet community.}, + keywords="IP, DIS, distributed, applications", + doi="10.17487/RFC2502", + } + +@misc{rfc2503, + author="R. Moulton and M. Needleman", + title="{MIME Types for Use with the ISO ILL Protocol}", + howpublished="RFC 2503 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2503", + pages="1--6", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2503.txt", + key="RFC 2503", + abstract={This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). This memo provides information for the Internet community.}, + keywords="multipurpose, mail, internet, extensions, media, type, interlibrary, loan", + doi="10.17487/RFC2503", + } + +@misc{rfc2504, + author="E. Guttman and L. Leong and G. Malkin", + title="{Users' Security Handbook}", + howpublished="RFC 2504 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2504", + pages="1--33", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2504.txt", + key="RFC 2504", + abstract={The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. This memo provides information for the Internet community.}, + keywords="encryption, networks, systems", + doi="10.17487/RFC2504", + } + +@misc{rfc2505, + author="G. Lindberg", + title="{Anti-Spam Recommendations for SMTP MTAs}", + howpublished="RFC 2505 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2505", + pages="1--24", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2505.txt", + key="RFC 2505", + abstract={This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="simple, mail, transfer, protocol, agents, sendmail", + doi="10.17487/RFC2505", + } + +@misc{rfc2506, + author="K. Holtman and A. Mutz and T. Hardie", + title="{Media Feature Tag Registration Procedure}", + howpublished="RFC 2506 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2506", + pages="1--12", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2506.txt", + key="RFC 2506", + abstract={This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="data, formats, vocabulary, negotiation, mechanism", + doi="10.17487/RFC2506", + } + +@misc{rfc2507, + author="M. Degermark and B. Nordgren and S. Pink", + title="{IP Header Compression}", + howpublished="RFC 2507 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2507", + pages="1--47", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2507.txt", + key="RFC 2507", + abstract={This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]}, + keywords="internet, protocol, tcp, transmission, control, bandwidth", + doi="10.17487/RFC2507", + } + +@misc{rfc2508, + author="S. Casner and V. Jacobson", + title="{Compressing IP/UDP/RTP Headers for Low-Speed Serial Links}", + howpublished="RFC 2508 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2508", + pages="1--24", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2508.txt", + key="RFC 2508", + abstract={This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK]}, + keywords="internet, protocol, user, datagram, real-timetransport, interoperability", + doi="10.17487/RFC2508", + } + +@misc{rfc2509, + author="M. Engan and S. Casner and C. Bormann", + title="{IP Header Compression over PPP}", + howpublished="RFC 2509 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2509", + pages="1--10", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3544", +url="https://www.rfc-editor.org/rfc/rfc2509.txt", + key="RFC 2509", + abstract={This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol. It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]}, + keywords="IPCOM-PPP, internet, protocol, point-to-point, datagrams", + doi="10.17487/RFC2509", + } + +@misc{rfc2510, + author="C. Adams and S. Farrell", + title="{Internet X.509 Public Key Infrastructure Certificate Management Protocols}", + howpublished="RFC 2510 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2510", + pages="1--72", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4210", +url="https://www.rfc-editor.org/rfc/rfc2510.txt", + key="RFC 2510", + abstract={This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]}, + keywords="PKICMP, pki, security, cryptographic, authentication", + doi="10.17487/RFC2510", + } + +@misc{rfc2511, + author="M. Myers and C. Adams and D. Solo and D. Kemp", + title="{Internet X.509 Certificate Request Message Format}", + howpublished="RFC 2511 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2511", + pages="1--25", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4211", +url="https://www.rfc-editor.org/rfc/rfc2511.txt", + key="RFC 2511", + abstract={This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]}, + keywords="X.509-CRMF, crmf, security, encryption, authenticaion", + doi="10.17487/RFC2511", + } + +@misc{rfc2512, + author="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad", + title="{Accounting Information for ATM Networks}", + howpublished="RFC 2512 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2512", + pages="1--15", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2512.txt", + key="RFC 2512", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]}, + keywords="mib, management, information, base, autonomous, transfer, mode", + doi="10.17487/RFC2512", + } + +@misc{rfc2513, + author="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad", + title="{Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks}", + howpublished="RFC 2513 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2513", + pages="1--29", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2513.txt", + key="RFC 2513", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]}, + keywords="mib, management, information, base", + doi="10.17487/RFC2513", + } + +@misc{rfc2514, + author="M. Noto and E. Spiegel and K. Tesink", + title="{Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management}", + howpublished="RFC 2514 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2514", + pages="1--20", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2514.txt", + key="RFC 2514", + abstract={This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]}, + keywords="ATM-TC-OID, asynchronous, transfer, mode, MIB, management, information, base", + doi="10.17487/RFC2514", + } + +@misc{rfc2515, + author="K. Tesink and Ed", + title="{Definitions of Managed Objects for ATM Management}", + howpublished="RFC 2515 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2515", + pages="1--87", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2515.txt", + key="RFC 2515", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]}, + keywords="ATM-MIBMAN, asynchronous, transfer, mode, MIB, management, information, base", + doi="10.17487/RFC2515", + } + +@misc{rfc2516, + author="L. Mamakos and K. Lidl and J. Evarts and D. Carrel and D. Simone and R. Wheeler", + title="{A Method for Transmitting PPP Over Ethernet (PPPoE)}", + howpublished="RFC 2516 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2516", + pages="1--17", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2516.txt", + key="RFC 2516", + abstract={This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community.}, + keywords="PPPOE, point-to-point, protocol, link, control, network, layer", + doi="10.17487/RFC2516", + } + +@misc{rfc2517, + author="R. Moats and R. Huber", + title="{Building Directories from DNS: Experiences from WWWSeeker}", + howpublished="RFC 2517 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2517", + pages="1--7", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2517.txt", + key="RFC 2517", + abstract={This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. This memo provides information for the Internet community.}, + keywords="domain, name, system, internet, world, wide, web", + doi="10.17487/RFC2517", + } + +@misc{rfc2518, + author="Y. Goland and E. Whitehead and A. Faizi and S. Carter and D. Jensen", + title="{HTTP Extensions for Distributed Authoring -- WEBDAV}", + howpublished="RFC 2518 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2518", + pages="1--94", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4918", +url="https://www.rfc-editor.org/rfc/rfc2518.txt", + key="RFC 2518", + abstract={This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]}, + keywords="WEBDAV, hypertext, transfer, protocol, web, content", + doi="10.17487/RFC2518", + } + +@misc{rfc2519, + author="E. Chen and J. Stewart", + title="{A Framework for Inter-Domain Route Aggregation}", + howpublished="RFC 2519 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2519", + pages="1--13", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2519.txt", + key="RFC 2519", + abstract={This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This memo provides information for the Internet community}, + keywords="IDRA, bgp, border, gateway, protocol, address, ip, internet", + doi="10.17487/RFC2519", + } + +@misc{rfc2520, + author="J. Luciani and H. Suzuki and N. Doraswamy and D. Horton", + title="{NHRP with Mobile NHCs}", + howpublished="RFC 2520 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2520", + pages="1--8", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2520.txt", + key="RFC 2520", + abstract={is document describes an extension to NHRP which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner. This memo defines an Experimental Protocol for the Internet community.}, + keywords="NHRP-MNHCS, next, hop, resolution, protocol, authentication, extension", + doi="10.17487/RFC2520", + } + +@misc{rfc2521, + author="P. Karn and W. Simpson", + title="{ICMP Security Failures Messages}", + howpublished="RFC 2521 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2521", + pages="1--9", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2521.txt", + key="RFC 2521", + abstract={This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). This document defines an Experimental Protocol for the Internet community.}, + keywords="ICMP-SEC, internet, control, message, protocol, ip", + doi="10.17487/RFC2521", + } + +@misc{rfc2522, + author="P. Karn and W. Simpson", + title="{Photuris: Session-Key Management Protocol}", + howpublished="RFC 2522 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2522", + pages="1--80", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2522.txt", + key="RFC 2522", + abstract={This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.}, + keywords="PHOTURIS-S, ip, internet, protocol, ah, esp", + doi="10.17487/RFC2522", + } + +@misc{rfc2523, + author="P. Karn and W. Simpson", + title="{Photuris: Extended Schemes and Attributes}", + howpublished="RFC 2523 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2523", + pages="1--21", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2523.txt", + key="RFC 2523", + abstract={Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. This document defines an Experimental Protocol for the Internet community.}, + keywords="PHOTURIS-E, ip, internet, protocol, security", + doi="10.17487/RFC2523", + } + +@misc{rfc2524, + author="M. Banan", + title="{Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3}", + howpublished="RFC 2524 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2524", + pages="1--83", + year=1999, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2524.txt", + key="RFC 2524", + abstract={This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community.}, + keywords="EMSD, wireless, IP, internet, protocol", + doi="10.17487/RFC2524", + } + +@misc{rfc2525, + author="V. Paxson and M. Allman and S. Dawson and W. Fenner and J. Griner and I. Heavens and K. Lahey and J. Semke and B. Volz", + title="{Known TCP Implementation Problems}", + howpublished="RFC 2525 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2525", + pages="1--61", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2525.txt", + key="RFC 2525", + abstract={This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community.}, + keywords="transmission, control, protocol", + doi="10.17487/RFC2525", + } + +@misc{rfc2526, + author="D. Johnson and S. Deering", + title="{Reserved IPv6 Subnet Anycast Addresses}", + howpublished="RFC 2526 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2526", + pages="1--7", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2526.txt", + key="RFC 2526", + abstract={This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. [STANDARDS-TRACK]}, + keywords="internet, protocol, routing, architecture", + doi="10.17487/RFC2526", + } + +@misc{rfc2527, + author="S. Chokhani and W. Ford", + title="{Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework}", + howpublished="RFC 2527 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2527", + pages="1--45", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3647", +url="https://www.rfc-editor.org/rfc/rfc2527.txt", + key="RFC 2527", + abstract={This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. This memo provides information for the Internet community.}, + keywords="pkix, encryption, security, authentication", + doi="10.17487/RFC2527", + } + +@misc{rfc2528, + author="R. Housley and W. Polk", + title="{Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates}", + howpublished="RFC 2528 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2528", + pages="1--9", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2528.txt", + key="RFC 2528", + abstract={This specification contains guidance on the use of the Internet Public Key Infrastructure certificates to convey Key Exchange Algorithm (KEA) keys. This memo provides information for the Internet community.}, + keywords="security, authentication, cryptology", + doi="10.17487/RFC2528", + } + +@misc{rfc2529, + author="B. Carpenter and C. Jung", + title="{Transmission of IPv6 over IPv4 Domains without Explicit Tunnels}", + howpublished="RFC 2529 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2529", + pages="1--10", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2529.txt", + key="RFC 2529", + abstract={This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]}, + keywords="link-local, link, local, addresses, internet, protocol, ip", + doi="10.17487/RFC2529", + } + +@misc{rfc2530, + author="D. Wing", + title="{Indicating Supported Media Features Using Extensions to DSN and MDN}", + howpublished="RFC 2530 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2530", + pages="1--5", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2530.txt", + key="RFC 2530", + abstract={This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]}, + keywords="message, disposition, notification, delivery, status", + doi="10.17487/RFC2530", + } + +@misc{rfc2531, + author="G. Klyne and L. McIntyre", + title="{Content Feature Schema for Internet Fax}", + howpublished="RFC 2531 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2531", + pages="1--51", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2879", +url="https://www.rfc-editor.org/rfc/rfc2531.txt", + key="RFC 2531", + abstract={This document defines a content feature schema that is a profile of the media feature registration mechanisms for use in performing capability identification between extended Internet fax systems. [STANDARDS-TRACK]}, + keywords="media, features, mechanism", + doi="10.17487/RFC2531", + } + +@misc{rfc2532, + author="L. Masinter and D. Wing", + title="{Extended Facsimile Using Internet Mail}", + howpublished="RFC 2532 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2532", + pages="1--12", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2532.txt", + key="RFC 2532", + abstract={This document describes extensions to ``Simple Mode of Facsimile Using Internet Mail'', and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK]}, + keywords="mail, user, fax", + doi="10.17487/RFC2532", + } + +@misc{rfc2533, + author="G. Klyne", + title="{A Syntax for Describing Media Feature Sets}", + howpublished="RFC 2533 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2533", + pages="1--37", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2738, 2938", +url="https://www.rfc-editor.org/rfc/rfc2533.txt", + key="RFC 2533", + abstract={This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. [STANDARDS-TRACK]}, + keywords="message, senders, recipients, file, format", + doi="10.17487/RFC2533", + } + +@misc{rfc2534, + author="L. Masinter and D. Wing and A. Mutz and K. Holtman", + title="{Media Features for Display, Print, and Fax}", + howpublished="RFC 2534 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2534", + pages="1--9", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2534.txt", + key="RFC 2534", + abstract={This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. [STANDARDS-TRACK]}, + keywords="data, format, vocabulary, negotiation, mechanisms", + doi="10.17487/RFC2534", + } + +@misc{rfc2535, + author="D. {Eastlake 3rd}", + title="{Domain Name System Security Extensions}", + howpublished="RFC 2535 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2535", + pages="1--47", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFCs 2931, 3007, 3008, 3090, 3226, 3445, 3597, 3655, 3658, 3755, 3757, 3845", +url="https://www.rfc-editor.org/rfc/rfc2535.txt", + key="RFC 2535", + abstract={This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]}, + keywords="DNS-SECEXT, dns, authentication", + doi="10.17487/RFC2535", + } + +@misc{rfc2536, + author="D. {Eastlake 3rd}", + title="{DSA KEYs and SIGs in the Domain Name System (DNS)}", + howpublished="RFC 2536 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2536", + pages="1--6", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6944", +url="https://www.rfc-editor.org/rfc/rfc2536.txt", + key="RFC 2536", + abstract={A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]}, + keywords="digital, signature, algorithm, signatures, cryptology", + doi="10.17487/RFC2536", + } + +@misc{rfc2537, + author="D. {Eastlake 3rd}", + title="{RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)}", + howpublished="RFC 2537 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2537", + pages="1--6", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3110", +url="https://www.rfc-editor.org/rfc/rfc2537.txt", + key="RFC 2537", + abstract={A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]}, + keywords="message, digest, signatures, cryptology, security", + doi="10.17487/RFC2537", + } + +@misc{rfc2538, + author="D. {Eastlake 3rd} and O. Gudmundsson", + title="{Storing Certificates in the Domain Name System (DNS)}", + howpublished="RFC 2538 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2538", + pages="1--10", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4398", +url="https://www.rfc-editor.org/rfc/rfc2538.txt", + key="RFC 2538", + abstract={Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]}, + keywords="SC-DNS, cryptology, authenticity", + doi="10.17487/RFC2538", + } + +@misc{rfc2539, + author="D. {Eastlake 3rd}", + title="{Storage of Diffie-Hellman Keys in the Domain Name System (DNS)}", + howpublished="RFC 2539 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2539", + pages="1--7", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6944", +url="https://www.rfc-editor.org/rfc/rfc2539.txt", + key="RFC 2539", + abstract={A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK]}, + keywords="DHK-DNS, cryptology, authentication, security, signatures, digital", + doi="10.17487/RFC2539", + } + +@misc{rfc2540, + author="D. {Eastlake 3rd}", + title="{Detached Domain Name System (DNS) Information}", + howpublished="RFC 2540 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2540", + pages="1--6", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2540.txt", + key="RFC 2540", + abstract={A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DNS-INFO, security, digital, signatures, authentication", + doi="10.17487/RFC2540", + } + +@misc{rfc2541, + author="D. {Eastlake 3rd}", + title="{DNS Security Operational Considerations}", + howpublished="RFC 2541 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2541", + pages="1--7", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4641", +url="https://www.rfc-editor.org/rfc/rfc2541.txt", + key="RFC 2541", + abstract={This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. This memo provides information for the Internet community.}, + keywords="DNS-SOC, domain, name, system, cryptology, resource, records, rrs", + doi="10.17487/RFC2541", + } + +@misc{rfc2542, + author="L. Masinter", + title="{Terminology and Goals for Internet Fax}", + howpublished="RFC 2542 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2542", + pages="1--20", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2542.txt", + key="RFC 2542", + abstract={This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. This memo provides information for the Internet community.}, + keywords="real-time, real, time, session, store, forward", + doi="10.17487/RFC2542", + } + +@misc{rfc2543, + author="M. Handley and H. Schulzrinne and E. Schooler and J. Rosenberg", + title="{SIP: Session Initiation Protocol}", + howpublished="RFC 2543 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2543", + pages="1--151", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 3261, 3262, 3263, 3264, 3265", +url="https://www.rfc-editor.org/rfc/rfc2543.txt", + key="RFC 2543", + abstract={The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. [STANDARDS-TRACK]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC2543", + } + +@misc{rfc2544, + author="S. Bradner and J. McQuaid", + title="{Benchmarking Methodology for Network Interconnect Devices}", + howpublished="RFC 2544 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2544", + pages="1--31", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6201, 6815", +url="https://www.rfc-editor.org/rfc/rfc2544.txt", + key="RFC 2544", + abstract={This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community.}, + keywords="testing, performance", + doi="10.17487/RFC2544", + } + +@misc{rfc2545, + author="P. Marques and F. Dupont", + title="{Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing}", + howpublished="RFC 2545 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2545", + pages="1--5", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2545.txt", + key="RFC 2545", + abstract={BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP\_REACH\_NLRI and MP\_UNREACH\_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]}, + keywords="border, gateway, protocol, idr, internet, routing", + doi="10.17487/RFC2545", + } + +@misc{rfc2546, + author="A. Durand and B. Buclin", + title="{6Bone Routing Practice}", + howpublished="RFC 2546 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2546", + pages="1--10", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2772", +url="https://www.rfc-editor.org/rfc/rfc2546.txt", + key="RFC 2546", + abstract={This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community.}, + keywords="IPv6, internet protocol", + doi="10.17487/RFC2546", + } + +@misc{rfc2547, + author="E. Rosen and Y. Rekhter", + title="{BGP/MPLS VPNs}", + howpublished="RFC 2547 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2547", + pages="1--25", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4364", +url="https://www.rfc-editor.org/rfc/rfc2547.txt", + key="RFC 2547", + abstract={This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. This memo provides information for the Internet community.}, + keywords="border, gateway, protocol, multiprotocol, label, switching, architecture, virtual, private, networks", + doi="10.17487/RFC2547", + } + +@misc{rfc2548, + author="G. Zorn", + title="{Microsoft Vendor-specific RADIUS Attributes}", + howpublished="RFC 2548 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2548", + pages="1--41", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2548.txt", + key="RFC 2548", + abstract={This document describes the set of Microsoft vendor-specific RADIUS attributes. This memo provides information for the Internet community.}, + keywords="attributes, remote, access, dialin, user, service, dial-in", + doi="10.17487/RFC2548", + } + +@misc{rfc2549, + author="D. Waitzman", + title="{IP over Avian Carriers with Quality of Service}", + howpublished="RFC 2549 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2549", + pages="1--6", + year=1999, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2549.txt", + key="RFC 2549", + abstract={This memo amends RFC 1149, ``A Standard for the Transmission of IP Datagrams on Avian Carriers'', with Quality of Service information. This is an experimental, not recommended standard. This memo defines an Experimental Protocol for the Internet community.}, + keywords="avian, carrier, april, fools, qos", + doi="10.17487/RFC2549", + } + +@misc{rfc2550, + author="S. Glassman and M. Manasse and J. Mogul", + title="{Y10K and Beyond}", + howpublished="RFC 2550 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2550", + pages="1--14", + year=1999, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2550.txt", + key="RFC 2550", + abstract={This specification provides a solution to the ``Y10K'' problem which has also been called the ``YAK'' problem (hex) and the ``YXK'' problem (Roman numerals). This memo provides information for the Internet community.}, + keywords="years, dates, formats, april, fools", + doi="10.17487/RFC2550", + } + +@misc{rfc2551, + author="S. Bradner", + title="{The Roman Standards Process -- Revision III}", + howpublished="RFC 2551 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2551", + pages="1--37", + year=1999, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2551.txt", + key="RFC 2551", + abstract={This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.}, + keywords="numerals, protocols, procedures, april, fools", + doi="10.17487/RFC2551", + } + +@misc{rfc2552, + author="M. Blinov and M. Bessonov and C. Clissmann", + title="{Architecture for the Information Brokerage in the ACTS Project GAIA}", + howpublished="RFC 2552 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2552", + pages="1--30", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2552.txt", + key="RFC 2552", + abstract={This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). This memo provides information for the Internet community.}, + keywords="electronic, systems, products", + doi="10.17487/RFC2552", + } + +@misc{rfc2553, + author="R. Gilligan and S. Thomson and J. Bound and W. Stevens", + title="{Basic Socket Interface Extensions for IPv6}", + howpublished="RFC 2553 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2553", + pages="1--41", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3493, updated by RFC 3152", +url="https://www.rfc-editor.org/rfc/rfc2553.txt", + key="RFC 2553", + abstract={TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. This memo provides information for the Internet community.}, + keywords="internet, protocol, api, application, program, interface, tcp, transmission control", + doi="10.17487/RFC2553", + } + +@misc{rfc2554, + author="J. Myers", + title="{SMTP Service Extension for Authentication}", + howpublished="RFC 2554 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2554", + pages="1--11", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4954", +url="https://www.rfc-editor.org/rfc/rfc2554.txt", + key="RFC 2554", + abstract={This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]}, + keywords="simple, mail, transfer, protocol, security, layer, sasl", + doi="10.17487/RFC2554", + } + +@misc{rfc2555, + author="RFC Editor and et al.", + title="{30 Years of RFCs}", + howpublished="RFC 2555 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2555", + pages="1--18", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2555.txt", + key="RFC 2555", + abstract={The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.}, + keywords="request, for, comments, series, documents, publication", + doi="10.17487/RFC2555", + } + +@misc{rfc2556, + author="S. Bradner", + title="{OSI connectionless transport services on top of UDP Applicability Statement for Historic Status}", + howpublished="RFC 2556 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2556", + pages="1--4", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2556.txt", + key="RFC 2556", + abstract={RFC 1240, ``OSI connectionless transport services on top of UDP'', was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility This memo provides information for the Internet community.}, + keywords="user, datagram, protocol, ISO, international, organization for standardization", + doi="10.17487/RFC2556", + } + +@misc{rfc2557, + author="J. Palme and A. Hopmann and N. Shelness", + title="{MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)}", + howpublished="RFC 2557 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2557", + pages="1--28", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2557.txt", + key="RFC 2557", + abstract={This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK]}, + keywords="MHTML, multipurpose, internet, mail, extensions, multimedia, uri, uniform, resource, identifiers", + doi="10.17487/RFC2557", + } + +@misc{rfc2558, + author="K. Tesink", + title="{Definitions of Managed Objects for the SONET/SDH Interface Type}", + howpublished="RFC 2558 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2558", + pages="1--74", + year=1999, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3592", +url="https://www.rfc-editor.org/rfc/rfc2558.txt", + key="RFC 2558", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]}, + keywords="MIB, Management, SNMP", + doi="10.17487/RFC2558", + } + +@misc{rfc2559, + author="S. Boeyen and T. Howes and P. Richard", + title="{Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2}", + howpublished="RFC 2559 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2559", + pages="1--13", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3494", +url="https://www.rfc-editor.org/rfc/rfc2559.txt", + key="RFC 2559", + abstract={Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]}, + keywords="X.500, LDAP, lightweight directory protocol", + doi="10.17487/RFC2559", + } + +@misc{rfc2560, + author="M. Myers and R. Ankney and A. Malpani and S. Galperin and C. Adams", + title="{X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP}", + howpublished="RFC 2560 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2560", + pages="1--23", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6960, updated by RFC 6277", +url="https://www.rfc-editor.org/rfc/rfc2560.txt", + key="RFC 2560", + abstract={This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]}, + keywords="PKIX, digital, security", + doi="10.17487/RFC2560", + } + +@misc{rfc2561, + author="K. White and R. Moore", + title="{Base Definitions of Managed Objects for TN3270E Using SMIv2}", + howpublished="RFC 2561 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2561", + pages="1--56", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2561.txt", + key="RFC 2561", + abstract={This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. [STANDARDS-TRACK]}, + keywords="MIB, management, information, base, structure, telnet", + doi="10.17487/RFC2561", + } + +@misc{rfc2562, + author="K. White and R. Moore", + title="{Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)}", + howpublished="RFC 2562 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2562", + pages="1--49", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2562.txt", + key="RFC 2562", + abstract={This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. [STANDARDS-TRACK]}, + keywords="TN2370E-RT-MIB, MIB, management, information, base, structure, telnet", + doi="10.17487/RFC2562", + } + +@misc{rfc2563, + author="R. Troll", + title="{DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients}", + howpublished="RFC 2563 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2563", + pages="1--9", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2563.txt", + key="RFC 2563", + abstract={This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol, internet, address", + doi="10.17487/RFC2563", + } + +@misc{rfc2564, + author="C. Kalbfleisch and C. Krupczak and R. Presuhn and J. Saperia", + title="{Application Management MIB}", + howpublished="RFC 2564 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2564", + pages="1--86", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2564.txt", + key="RFC 2564", + abstract={This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. [STANDARDS-TRACK]}, + keywords="APP-MIB, management, information, base", + doi="10.17487/RFC2564", + } + +@misc{rfc2565, + author="R. {Herriot (Ed.)} and S. Butler and P. Moore and R. Turner", + title="{Internet Printing Protocol/1.0: Encoding and Transport}", + howpublished="RFC 2565 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2565", + pages="1--37", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2910", +url="https://www.rfc-editor.org/rfc/rfc2565.txt", + key="RFC 2565", + abstract={This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called ``application/ipp''. This document also defines the rules for transporting over HTTP a message body whose Content-Type is ``application/ipp''. This document defines an Experimental protocol for the Internet community.}, + keywords="IPP-E-T, IPP, application, media-type, media, type", + doi="10.17487/RFC2565", + } + +@misc{rfc2566, + author="R. deBry and T. Hastings and R. Herriot and S. Isaacson and P. Powell", + title="{Internet Printing Protocol/1.0: Model and Semantics}", + howpublished="RFC 2566 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2566", + pages="1--173", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2911", +url="https://www.rfc-editor.org/rfc/rfc2566.txt", + key="RFC 2566", + abstract={This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. This document also addresses security, internationalization, and directory issues. This memo defines an Experimental Protocol for the Internet community.}, + keywords="IPP-M-S, IPP, application, media-type, job", + doi="10.17487/RFC2566", + } + +@misc{rfc2567, + author="F. Wright", + title="{Design Goals for an Internet Printing Protocol}", + howpublished="RFC 2567 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2567", + pages="1--43", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2567.txt", + key="RFC 2567", + abstract={This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. This memo defines an Experimental Protocol for the Internet community.}, + keywords="IPP-DG, IPP, application, media-type, media, type", + doi="10.17487/RFC2567", + } + +@misc{rfc2568, + author="S. Zilles", + title="{Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol}", + howpublished="RFC 2568 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2568", + pages="1--10", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2568.txt", + key="RFC 2568", + abstract={This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community.}, + keywords="IPP-RAT, IPP, application, media-type, media, type", + doi="10.17487/RFC2568", + } + +@misc{rfc2569, + author="R. {Herriot (Ed.)} and T. Hastings and N. Jacobs and J. Martin", + title="{Mapping between LPD and IPP Protocols}", + howpublished="RFC 2569 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2569", + pages="1--28", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2569.txt", + key="RFC 2569", + abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. This memo defines an Experimental Protocol for the Internet community.}, + keywords="application, media-type, media, type, internet, printing, protocol, line, printer, daemon", + doi="10.17487/RFC2569", + } + +@misc{rfc2570, + author="J. Case and R. Mundy and D. Partain and B. Stewart", + title="{Introduction to Version 3 of the Internet-standard Network Management Framework}", + howpublished="RFC 2570 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2570", + pages="1--23", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3410", +url="https://www.rfc-editor.org/rfc/rfc2570.txt", + key="RFC 2570", + abstract={The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This memo provides information for the Internet community.}, + keywords="snmp, simple, protocol", + doi="10.17487/RFC2570", + } + +@misc{rfc2571, + author="B. Wijnen and D. Harrington and R. Presuhn", + title="{An Architecture for Describing SNMP Management Frameworks}", + howpublished="RFC 2571 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2571", + pages="1--62", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3411", +url="https://www.rfc-editor.org/rfc/rfc2571.txt", + key="RFC 2571", + abstract={This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK]}, + keywords="ARCH-SNMP, simple, protocol, network, management", + doi="10.17487/RFC2571", + } + +@misc{rfc2572, + author="J. Case and D. Harrington and R. Presuhn and B. Wijnen", + title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 2572 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2572", + pages="1--44", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3412", +url="https://www.rfc-editor.org/rfc/rfc2572.txt", + key="RFC 2572", + abstract={This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]}, + keywords="MPD-SNMP, processing, models, multiple", + doi="10.17487/RFC2572", + } + +@misc{rfc2573, + author="D. Levi and P. Meyer and B. Stewart", + title="{SNMP Applications}", + howpublished="RFC 2573 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2573", + pages="1--72", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3413", +url="https://www.rfc-editor.org/rfc/rfc2573.txt", + key="RFC 2573", + abstract={This memo describes five types of SNMP applications which make use of an SNMP engine. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy fowarding. [STANDARDS-TRACK]}, + keywords="SNMP-APP, simple, network, management, protocol, proxy, operations, command", + doi="10.17487/RFC2573", + } + +@misc{rfc2574, + author="U. Blumenthal and B. Wijnen", + title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}", + howpublished="RFC 2574 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2574", + pages="1--86", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3414", +url="https://www.rfc-editor.org/rfc/rfc2574.txt", + key="RFC 2574", + abstract={This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]}, + keywords="USM-SNMPV3, message, level, mib, information, base", + doi="10.17487/RFC2574", + } + +@misc{rfc2575, + author="B. Wijnen and R. Presuhn and K. McCloghrie", + title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 2575 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2575", + pages="1--38", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3415", +url="https://www.rfc-editor.org/rfc/rfc2575.txt", + key="RFC 2575", + abstract={This document describes the View-based Access Control Model for use in the SNMP architecture (RFC2571). It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]}, + keywords="VACM-SNMP, mib, information, base", + doi="10.17487/RFC2575", + } + +@misc{rfc2576, + author="R. Frye and D. Levi and S. Routhier and B. Wijnen", + title="{Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework}", + howpublished="RFC 2576 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2576", + pages="1--44", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3584", +url="https://www.rfc-editor.org/rfc/rfc2576.txt", + key="RFC 2576", + abstract={The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]}, + keywords="SNMP, simple network, management protocol, mib, information, base", + doi="10.17487/RFC2576", + } + +@misc{rfc2577, + author="M. Allman and S. Ostermann", + title="{FTP Security Considerations}", + howpublished="RFC 2577 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2577", + pages="1--8", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2577.txt", + key="RFC 2577", + abstract={This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. This memo provides information for the Internet community.}, + keywords="FTP-SEC, file, transfer, protocol, bounce, attack, password, server", + doi="10.17487/RFC2577", + } + +@misc{rfc2578, + author="K. {McCloghrie (Ed.)} and D. {Perkins (Ed.)} and J. {Schoenwaelder (Ed.)}", + title="{Structure of Management Information Version 2 (SMIv2)}", + howpublished="RFC 2578 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2578", + pages="1--42", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2578.txt", + key="RFC 2578", + abstract={It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]}, + keywords="SMIv2, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC2578", + } + +@misc{rfc2579, + author="K. {McCloghrie (Ed.)} and D. {Perkins (Ed.)} and J. {Schoenwaelder (Ed.)}", + title="{Textual Conventions for SMIv2}", + howpublished="RFC 2579 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2579", + pages="1--25", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2579.txt", + key="RFC 2579", + abstract={It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]}, + keywords="CONV-MIB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC2579", + } + +@misc{rfc2580, + author="K. {McCloghrie (Ed.)} and D. {Perkins (Ed.)} and J. {Schoenwaelder (Ed.)}", + title="{Conformance Statements for SMIv2}", + howpublished="RFC 2580 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2580", + pages="1--29", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2580.txt", + key="RFC 2580", + abstract={Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]}, + keywords="CONF-MIB, simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC2580", + } + +@misc{rfc2581, + author="M. Allman and V. Paxson and W. Stevens", + title="{TCP Congestion Control}", + howpublished="RFC 2581 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2581", + pages="1--14", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5681, updated by RFC 3390", +url="https://www.rfc-editor.org/rfc/rfc2581.txt", + key="RFC 2581", + abstract={This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. [STANDARDS-TRACK]}, + keywords="TCP-CC", + doi="10.17487/RFC2581", + } + +@misc{rfc2582, + author="S. Floyd and T. Henderson", + title="{The NewReno Modification to TCP's Fast Recovery Algorithm}", + howpublished="RFC 2582 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2582", + pages="1--12", + year=1999, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3782", +url="https://www.rfc-editor.org/rfc/rfc2582.txt", + key="RFC 2582", + abstract={This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This memo defines an Experimental Protocol for the Internet community.}, + keywords="Transmission, Control, Protocol", + doi="10.17487/RFC2582", + } + +@misc{rfc2583, + author="R. Carlson and L. Winkler", + title="{Guidelines for Next Hop Client (NHC) Developers}", + howpublished="RFC 2583 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2583", + pages="1--9", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2583.txt", + key="RFC 2583", + abstract={This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community.}, + keywords="NHRP, resolution, protocol, IP, internet", + doi="10.17487/RFC2583", + } + +@misc{rfc2584, + author="B. Clouston and B. Moore", + title="{Definitions of Managed Objects for APPN/HPR in IP Networks}", + howpublished="RFC 2584 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2584", + pages="1--21", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2584.txt", + key="RFC 2584", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. [STANDARDS-TRACK]}, + keywords="internet, protocol, MIB, management, information, base, high, performance, routing", + doi="10.17487/RFC2584", + } + +@misc{rfc2585, + author="R. Housley and P. Hoffman", + title="{Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP}", + howpublished="RFC 2585 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2585", + pages="1--8", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2585.txt", + key="RFC 2585", + abstract={The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK]}, + keywords="file, transfer, hypertext, PKI", + doi="10.17487/RFC2585", + } + +@misc{rfc2586, + author="J. Salsman and H. Alvestrand", + title="{The Audio/L16 MIME content type}", + howpublished="RFC 2586 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2586", + pages="1--5", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2586.txt", + key="RFC 2586", + abstract={This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community.}, + keywords="AUDIO/L16, media-type, application, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2586", + } + +@misc{rfc2587, + author="S. Boeyen and T. Howes and P. Richard", + title="{Internet X.509 Public Key Infrastructure LDAPv2 Schema}", + howpublished="RFC 2587 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2587", + pages="1--8", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4523", +url="https://www.rfc-editor.org/rfc/rfc2587.txt", + key="RFC 2587", + abstract={The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol, pkix", + doi="10.17487/RFC2587", + } + +@misc{rfc2588, + author="R. Finlayson", + title="{IP Multicast and Firewalls}", + howpublished="RFC 2588 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2588", + pages="1--12", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2588.txt", + key="RFC 2588", + abstract={In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.}, + keywords="Internet, Protocol, security, gateway, traffic", + doi="10.17487/RFC2588", + } + +@misc{rfc2589, + author="Y. Yaacovi and M. Wahl and T. Genovese", + title="{Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services}", + howpublished="RFC 2589 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2589", + pages="1--12", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2589.txt", + key="RFC 2589", + abstract={This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]}, + keywords="LDAPv3, request, response, operations", + doi="10.17487/RFC2589", + } + +@misc{rfc2590, + author="A. Conta and A. Malis and M. Mueller", + title="{Transmission of IPv6 Packets over Frame Relay Networks Specification}", + howpublished="RFC 2590 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2590", + pages="1--19", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc2590.txt", + key="RFC 2590", + abstract={This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]}, + keywords="internet, Protocol, format, link-local", + doi="10.17487/RFC2590", + } + +@misc{rfc2591, + author="D. Levi and J. Schoenwaelder", + title="{Definitions of Managed Objects for Scheduling Management Operations}", + howpublished="RFC 2591 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2591", + pages="1--25", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3231", +url="https://www.rfc-editor.org/rfc/rfc2591.txt", + key="RFC 2591", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]}, + keywords="mib, information, base", + doi="10.17487/RFC2591", + } + +@misc{rfc2592, + author="D. Levi and J. Schoenwaelder", + title="{Definitions of Managed Objects for the Delegation of Management Script}", + howpublished="RFC 2592 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2592", + pages="1--53", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3165", +url="https://www.rfc-editor.org/rfc/rfc2592.txt", + key="RFC 2592", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]}, + keywords="mib, information, base", + doi="10.17487/RFC2592", + } + +@misc{rfc2593, + author="J. Schoenwaelder and J. Quittek", + title="{Script MIB Extensibility Protocol Version 1.0}", + howpublished="RFC 2593 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2593", + pages="1--22", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3179", +url="https://www.rfc-editor.org/rfc/rfc2593.txt", + key="RFC 2593", + abstract={The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. This memo defines an Experimental Protocol for the Internet community.}, + keywords="management, information, base, smx, language, specific", + doi="10.17487/RFC2593", + } + +@misc{rfc2594, + author="H. Hazewinkel and C. Kalbfleisch and J. Schoenwaelder", + title="{Definitions of Managed Objects for WWW Services}", + howpublished="RFC 2594 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2594", + pages="1--43", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2594.txt", + key="RFC 2594", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. [STANDARDS-TRACK]}, + keywords="management, information, base, mib, world, wide, web", + doi="10.17487/RFC2594", + } + +@misc{rfc2595, + author="C. Newman", + title="{Using TLS with IMAP, POP3 and ACAP}", + howpublished="RFC 2595 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2595", + pages="1--15", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4616, 7817, 8314", +url="https://www.rfc-editor.org/rfc/rfc2595.txt", + key="RFC 2595", + abstract={Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]}, + keywords="application, configuration, access, protocol, post, office, internet, message, transport, layer, security", + doi="10.17487/RFC2595", + } + +@misc{rfc2596, + author="M. Wahl and T. Howes", + title="{Use of Language Codes in LDAP}", + howpublished="RFC 2596 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2596", + pages="1--9", + year=1999, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3866", +url="https://www.rfc-editor.org/rfc/rfc2596.txt", + key="RFC 2596", + abstract={This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol, servers", + doi="10.17487/RFC2596", + } + +@misc{rfc2597, + author="J. Heinanen and F. Baker and W. Weiss and J. Wroclawski", + title="{Assured Forwarding PHB Group}", + howpublished="RFC 2597 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2597", + pages="1--11", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3260", +url="https://www.rfc-editor.org/rfc/rfc2597.txt", + key="RFC 2597", + abstract={This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]}, + keywords="per-hop-behaviour, differentiated, services, af, assumed, forwarding", + doi="10.17487/RFC2597", + } + +@misc{rfc2598, + author="V. Jacobson and K. Nichols and K. Poduri", + title="{An Expedited Forwarding PHB}", + howpublished="RFC 2598 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2598", + pages="1--11", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3246", +url="https://www.rfc-editor.org/rfc/rfc2598.txt", + key="RFC 2598", + abstract={The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. [STANDARDS-TRACK]}, + keywords="per-hop-forwarding, behavior, differentiated, services, ef", + doi="10.17487/RFC2598", + } + +@misc{rfc2599, + author="A. DeLaCruz", + title="{Request for Comments Summary RFC Numbers 2500-2599}", + howpublished="RFC 2599 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2599", + pages="1--23", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2599.txt", + key="RFC 2599", + doi="10.17487/RFC2599", + } + +@misc{rfc2600, + author="J. Reynolds and R. Braden", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2600 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2600", + pages="1--31", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2700", +url="https://www.rfc-editor.org/rfc/rfc2600.txt", + key="RFC 2600", + abstract={This memo is published by the RFC Editor in accordance with Section 2.1 of ``The Internet Standards Process -- Revision 3'', RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see https://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]}, + keywords="IAB, official, protocol, standards", + doi="10.17487/RFC2600", + } + +@misc{rfc2601, + author="M. Davison", + title="{ILMI-Based Server Discovery for ATMARP}", + howpublished="RFC 2601 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2601", + pages="1--6", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2601.txt", + key="RFC 2601", + abstract={This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. [STANDARDS-TRACK]}, + keywords="integrated, local, management, interface, asynchronous, transfer, mode, address, resolution, protocol", + doi="10.17487/RFC2601", + } + +@misc{rfc2602, + author="M. Davison", + title="{ILMI-Based Server Discovery for MARS}", + howpublished="RFC 2602 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2602", + pages="1--6", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2602.txt", + key="RFC 2602", + abstract={This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. [STANDARDS-TRACK]}, + keywords="integrated, local, management, interface, asynchronous, transfer, mode, address, resolution, protocol", + doi="10.17487/RFC2602", + } + +@misc{rfc2603, + author="M. Davison", + title="{ILMI-Based Server Discovery for NHRP}", + howpublished="RFC 2603 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2603", + pages="1--6", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2603.txt", + key="RFC 2603", + abstract={This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. [STANDARDS-TRACK]}, + keywords="integrated, local, management, interface, next, hop, resolution, protocol", + doi="10.17487/RFC2603", + } + +@misc{rfc2604, + author="R. Gellens", + title="{Wireless Device Configuration (OTASP/OTAPA) via ACAP}", + howpublished="RFC 2604 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2604", + pages="1--29", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2636", +url="https://www.rfc-editor.org/rfc/rfc2604.txt", + key="RFC 2604", + abstract={This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.}, + keywords="over-the-air, ota, application, configuration, access, protocol", + doi="10.17487/RFC2604", + } + +@misc{rfc2605, + author="G. Mansfield and S. Kille", + title="{Directory Server Monitoring MIB}", + howpublished="RFC 2605 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2605", + pages="1--26", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2605.txt", + key="RFC 2605", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]}, + keywords="management information base, network, services", + doi="10.17487/RFC2605", + } + +@misc{rfc2606, + author="D. {Eastlake 3rd} and A. Panitz", + title="{Reserved Top Level DNS Names}", + howpublished="RFC 2606 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2606", + pages="1--5", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6761", +url="https://www.rfc-editor.org/rfc/rfc2606.txt", + key="RFC 2606", + abstract={To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="domain, name, system, private", + doi="10.17487/RFC2606", + } + +@misc{rfc2607, + author="B. Aboba and J. Vollbrecht", + title="{Proxy Chaining and Policy Implementation in Roaming}", + howpublished="RFC 2607 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2607", + pages="1--15", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2607.txt", + key="RFC 2607", + abstract={This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community.}, + keywords="network, access, server, identifier, radius", + doi="10.17487/RFC2607", + } + +@misc{rfc2608, + author="E. Guttman and C. Perkins and J. Veizades and M. Day", + title="{Service Location Protocol, Version 2}", + howpublished="RFC 2608 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2608", + pages="1--54", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3224", +url="https://www.rfc-editor.org/rfc/rfc2608.txt", + key="RFC 2608", + abstract={The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]}, + keywords="SLP, network, services", + doi="10.17487/RFC2608", + } + +@misc{rfc2609, + author="E. Guttman and C. Perkins and J. Kempf", + title="{Service Templates and Service: Schemes}", + howpublished="RFC 2609 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2609", + pages="1--33", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2609.txt", + key="RFC 2609", + abstract={This document describes a formal procedure for defining and standardizing new service types and attributes for use with the ``service:'' scheme. [STANDARDS-TRACK]}, + keywords="service, location, protocol, slp, url, universal, resource, locator", + doi="10.17487/RFC2609", + } + +@misc{rfc2610, + author="C. Perkins and E. Guttman", + title="{DHCP Options for Service Location Protocol}", + howpublished="RFC 2610 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2610", + pages="1--6", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2610.txt", + key="RFC 2610", + abstract={The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. [STANDARDS-TRACK]}, + keywords="slp, dynamic, host, configuration, protocol", + doi="10.17487/RFC2610", + } + +@misc{rfc2611, + author="L. Daigle and D. van Gulik and R. Iannella and P. Faltstrom", + title="{URN Namespace Definition Mechanisms}", + howpublished="RFC 2611 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2611", + pages="1--14", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3406", +url="https://www.rfc-editor.org/rfc/rfc2611.txt", + key="RFC 2611", + abstract={This document lays out general definitions of and mechanisms for establishing URN ``namespaces''. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="uniform, resource, names, namespaces, syntax", + doi="10.17487/RFC2611", + } + +@misc{rfc2612, + author="C. Adams and J. Gilchrist", + title="{The CAST-256 Encryption Algorithm}", + howpublished="RFC 2612 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2612", + pages="1--19", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2612.txt", + key="RFC 2612", + abstract={This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). This memo provides information for the Internet community.}, + keywords="security, cryptology", + doi="10.17487/RFC2612", + } + +@misc{rfc2613, + author="R. Waterman and B. Lahaye and D. Romascanu and S. Waldbusser", + title="{Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0}", + howpublished="RFC 2613 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2613", + pages="1--44", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2613.txt", + key="RFC 2613", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. [STANDARDS-TRACK]}, + keywords="smon, management, information, base", + doi="10.17487/RFC2613", + } + +@misc{rfc2614, + author="J. Kempf and E. Guttman", + title="{An API for Service Location}", + howpublished="RFC 2614 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2614", + pages="1--91", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2614.txt", + key="RFC 2614", + abstract={This document describes standardized APIs for SLP in C and Java. This memo provides information for the Internet community.}, + keywords="slp, application, program, interface", + doi="10.17487/RFC2614", + } + +@misc{rfc2615, + author="A. Malis and W. Simpson", + title="{PPP over SONET/SDH}", + howpublished="RFC 2615 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2615", + pages="1--10", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2615.txt", + key="RFC 2615", + abstract={This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS-TRACK]}, + keywords="point-to-point protocol, synchronous, optical, network, digital, heirarchy", + doi="10.17487/RFC2615", + } + +@misc{rfc2616, + author="R. Fielding and J. Gettys and J. Mogul and H. Frystyk and L. Masinter and P. Leach and T. Berners-Lee", + title="{Hypertext Transfer Protocol -- HTTP/1.1}", + howpublished="RFC 2616 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2616", + pages="1--176", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 7230, 7231, 7232, 7233, 7234, 7235, updated by RFCs 2817, 5785, 6266, 6585", +url="https://www.rfc-editor.org/rfc/rfc2616.txt", + key="RFC 2616", + abstract={HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as ``HTTP/1.1'', and is an update to RFC 2068. [STANDARDS-TRACK]}, + keywords="HTTP, World Wide Web, WWW, hypermedia", + doi="10.17487/RFC2616", + } + +@misc{rfc2617, + author="J. Franks and P. Hallam-Baker and J. Hostetler and S. Lawrence and P. Leach and A. Luotonen and L. Stewart", + title="{HTTP Authentication: Basic and Digest Access Authentication}", + howpublished="RFC 2617 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2617", + pages="1--34", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 7235, 7615, 7616, 7617", +url="https://www.rfc-editor.org/rfc/rfc2617.txt", + key="RFC 2617", + abstract={This document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as ``Digest Access Authentication''. [STANDARDS-TRACK]}, + keywords="security, encryption, hypertext, transfer, protocol", + doi="10.17487/RFC2617", + } + +@misc{rfc2618, + author="B. Aboba and G. Zorn", + title="{RADIUS Authentication Client MIB}", + howpublished="RFC 2618 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2618", + pages="1--14", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4668", +url="https://www.rfc-editor.org/rfc/rfc2618.txt", + key="RFC 2618", + abstract={This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK]}, + keywords="management, information, base, security, remote, access, dialin, user, service", + doi="10.17487/RFC2618", + } + +@misc{rfc2619, + author="G. Zorn and B. Aboba", + title="{RADIUS Authentication Server MIB}", + howpublished="RFC 2619 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2619", + pages="1--16", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4669", +url="https://www.rfc-editor.org/rfc/rfc2619.txt", + key="RFC 2619", + abstract={This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK]}, + keywords="management, information, base, security, remote, access, dialin, user, service", + doi="10.17487/RFC2619", + } + +@misc{rfc2620, + author="B. Aboba and G. Zorn", + title="{RADIUS Accounting Client MIB}", + howpublished="RFC 2620 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2620", + pages="1--13", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4670", +url="https://www.rfc-editor.org/rfc/rfc2620.txt", + key="RFC 2620", + abstract={This memo defines a set of extensions which instrument RADIUS accounting client functions. This memo provides information for the Internet community.}, + keywords="management, information, base, security, remote, access, dialin, user, service", + doi="10.17487/RFC2620", + } + +@misc{rfc2621, + author="G. Zorn and B. Aboba", + title="{RADIUS Accounting Server MIB}", + howpublished="RFC 2621 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2621", + pages="1--15", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4671", +url="https://www.rfc-editor.org/rfc/rfc2621.txt", + key="RFC 2621", + abstract={This memo defines a set of extensions which instrument RADIUS accounting server functions. This memo provides information for the Internet community.}, + keywords="management, information, base, security, remote, access,dialin, user, service", + doi="10.17487/RFC2621", + } + +@misc{rfc2622, + author="C. Alaettinoglu and C. Villamizar and E. Gerich and D. Kessens and D. Meyer and T. Bates and D. Karrenberg and M. Terpstra", + title="{Routing Policy Specification Language (RPSL)}", + howpublished="RFC 2622 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2622", + pages="1--69", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4012, 7909", +url="https://www.rfc-editor.org/rfc/rfc2622.txt", + key="RFC 2622", + abstract={RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]}, + keywords="RPSL, internet, policy, hierarchy, network, configuration", + doi="10.17487/RFC2622", + } + +@misc{rfc2623, + author="M. Eisler", + title="{NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC\_GSS and Kerberos V5}", + howpublished="RFC 2623 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2623", + pages="1--19", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2623.txt", + key="RFC 2623", + abstract={This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC\_GSS security flavor protocol and Kerberos V5. [STANDARDS-TRACK]}, + keywords="network, file, system, remote, procedure, call, architecture", + doi="10.17487/RFC2623", + } + +@misc{rfc2624, + author="S. Shepler", + title="{NFS Version 4 Design Considerations}", + howpublished="RFC 2624 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2624", + pages="1--22", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2624.txt", + key="RFC 2624", + abstract={This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. This memo provides information for the Internet community.}, + keywords="network, file, system", + doi="10.17487/RFC2624", + } + +@misc{rfc2625, + author="M. Rajagopal and R. Bhagwat and W. Rickard", + title="{IP and ARP over Fibre Channel}", + howpublished="RFC 2625 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2625", + pages="1--63", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4338", +url="https://www.rfc-editor.org/rfc/rfc2625.txt", + key="RFC 2625", + abstract={The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK]}, + keywords="internet, protocal, address, resolution", + doi="10.17487/RFC2625", + } + +@misc{rfc2626, + author="P. Nesser II", + title="{The Internet and the Millennium Problem (Year 2000)}", + howpublished="RFC 2626 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2626", + pages="1--275", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2626.txt", + key="RFC 2626", + abstract={The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of ``period'' problems were discovered, where a time field would ``roll over'' as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. This memo provides information for the Internet community.}, + keywords="Y2K", + doi="10.17487/RFC2626", + } + +@misc{rfc2627, + author="D. Wallner and E. Harder and R. Agee", + title="{Key Management for Multicast: Issues and Architectures}", + howpublished="RFC 2627 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2627", + pages="1--23", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2627.txt", + key="RFC 2627", + abstract={This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.}, + keywords="communication, sessions, net key, rekey", + doi="10.17487/RFC2627", + } + +@misc{rfc2628, + author="V. Smyslov", + title="{Simple Cryptographic Program Interface (Crypto API)}", + howpublished="RFC 2628 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2628", + pages="1--30", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2628.txt", + key="RFC 2628", + abstract={This document describes a simple Application Program Interface to cryptographic functions. This memo provides information for the Internet community.}, + keywords="application, security", + doi="10.17487/RFC2628", + } + +@misc{rfc2629, + author="M. Rose", + title="{Writing I-Ds and RFCs using XML}", + howpublished="RFC 2629 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2629", + pages="1--31", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7749", +url="https://www.rfc-editor.org/rfc/rfc2629.txt", + key="RFC 2629", + abstract={This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.}, + keywords="internet-drafts, extensible markup, language, source format", + doi="10.17487/RFC2629", + } + +@misc{rfc2630, + author="R. Housley", + title="{Cryptographic Message Syntax}", + howpublished="RFC 2630 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2630", + pages="1--60", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 3369, 3370", +url="https://www.rfc-editor.org/rfc/rfc2630.txt", + key="RFC 2630", + abstract={This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]}, + keywords="encryption, certificate, key, management", + doi="10.17487/RFC2630", + } + +@misc{rfc2631, + author="E. Rescorla", + title="{Diffie-Hellman Key Agreement Method}", + howpublished="RFC 2631 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2631", + pages="1--13", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2631.txt", + key="RFC 2631", + abstract={This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]}, + keywords="encryption, management, certificate", + doi="10.17487/RFC2631", + } + +@misc{rfc2632, + author="B. {Ramsdell (Ed.)}", + title="{S/MIME Version 3 Certificate Handling}", + howpublished="RFC 2632 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2632", + pages="1--13", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3850", +url="https://www.rfc-editor.org/rfc/rfc2632.txt", + key="RFC 2632", + abstract={S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]}, + keywords="encryption, certificate, multipurpose, internet, mail, extensions, secure", + doi="10.17487/RFC2632", + } + +@misc{rfc2633, + author="B. {Ramsdell (Ed.)}", + title="{S/MIME Version 3 Message Specification}", + howpublished="RFC 2633 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2633", + pages="1--32", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3851", +url="https://www.rfc-editor.org/rfc/rfc2633.txt", + key="RFC 2633", + abstract={This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]}, + keywords="secure, multipurpose, internet, mail, extensions, encryption", + doi="10.17487/RFC2633", + } + +@misc{rfc2634, + author="P. {Hoffman (Ed.)}", + title="{Enhanced Security Services for S/MIME}", + howpublished="RFC 2634 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2634", + pages="1--58", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5035", +url="https://www.rfc-editor.org/rfc/rfc2634.txt", + key="RFC 2634", + abstract={This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]}, + keywords="secure, multipurpose, internet, mail, extensions, encryption", + doi="10.17487/RFC2634", + } + +@misc{rfc2635, + author="S. Hambridge and A. Lunde", + title="{DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)}", + howpublished="RFC 2635 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2635", + pages="1--18", + year=1999, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2635.txt", + key="RFC 2635", + abstract={This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. This memo provides information for the Internet community.}, + keywords="electronic, mail, email, users, administrators, managers", + doi="10.17487/RFC2635", + } + +@misc{rfc2636, + author="R. Gellens", + title="{Wireless Device Configuration (OTASP/OTAPA) via ACAP}", + howpublished="RFC 2636 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2636", + pages="1--29", + year=1999, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2636.txt", + key="RFC 2636", + abstract={This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.}, + keywords="over-the-air, ota, application, configuration, access, protocol", + doi="10.17487/RFC2636", + } + +@misc{rfc2637, + author="K. Hamzeh and G. Pall and W. Verthein and J. Taarud and W. Little and G. Zorn", + title="{Point-to-Point Tunneling Protocol (PPTP)}", + howpublished="RFC 2637 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2637", + pages="1--57", + year=1999, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2637.txt", + key="RFC 2637", + abstract={This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.}, + keywords="IP, tunnel, encapsulation", + doi="10.17487/RFC2637", + } + +@misc{rfc2638, + author="K. Nichols and V. Jacobson and L. Zhang", + title="{A Two-bit Differentiated Services Architecture for the Internet}", + howpublished="RFC 2638 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2638", + pages="1--26", + year=1999, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2638.txt", + key="RFC 2638", + abstract={This document presents a differentiated services architecture for the internet. This memo provides information for the Internet community.}, + keywords="IP, internet protocol, header, packets", + doi="10.17487/RFC2638", + } + +@misc{rfc2639, + author="T. Hastings and C. Manros", + title="{Internet Printing Protocol/1.0: Implementer's Guide}", + howpublished="RFC 2639 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2639", + pages="1--64", + year=1999, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3196", +url="https://www.rfc-editor.org/rfc/rfc2639.txt", + key="RFC 2639", + abstract={This document contains information that supplements the IPP Model and Semantics and the IPP Transport and Encoding documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. This memo provides information for the Internet community.}, + keywords="IPP, client, object", + doi="10.17487/RFC2639", + } + +@misc{rfc2640, + author="B. Curtin", + title="{Internationalization of the File Transfer Protocol}", + howpublished="RFC 2640 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2640", + pages="1--27", + year=1999, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2640.txt", + key="RFC 2640", + abstract={This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. [STANDARDS-TRACK]}, + keywords="ftp, character sets, languages", + doi="10.17487/RFC2640", + } + +@misc{rfc2641, + author="D. Hamilton and D. Ruffen", + title="{Cabletron's VlanHello Protocol Specification Version 4}", + howpublished="RFC 2641 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2641", + pages="1--17", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2641.txt", + key="RFC 2641", + abstract={The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. This memo provides information for the Internet community.}, + keywords="ISMP, inter switch, message, protocol, switches", + doi="10.17487/RFC2641", + } + +@misc{rfc2642, + author="L. Kane", + title="{Cabletron's VLS Protocol Specification}", + howpublished="RFC 2642 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2642", + pages="1--95", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2642.txt", + key="RFC 2642", + abstract={VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. This memo provides information for the Internet community.}, + keywords="Virtual, LAN, link, ISMP, inter switch, message, routing", + doi="10.17487/RFC2642", + } + +@misc{rfc2643, + author="D. Ruffen and T. Len and J. Yanacek", + title="{Cabletron's SecureFast VLAN Operational Model}", + howpublished="RFC 2643 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2643", + pages="1--60", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2643.txt", + key="RFC 2643", + abstract={Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. This memo provides information for the Internet community.}, + keywords="SFVLAN, switching, data packets, vitrual LANs", + doi="10.17487/RFC2643", + } + +@misc{rfc2644, + author="D. Senie", + title="{Changing the Default for Directed Broadcasts in Routers}", + howpublished="RFC 2644 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2644", + pages="1--4", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2644.txt", + key="RFC 2644", + abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.}, + keywords="smurf, amplifiers, denial of service", + doi="10.17487/RFC2644", + } + +@misc{rfc2645, + author="R. Gellens", + title="{ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses}", + howpublished="RFC 2645 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2645", + pages="1--9", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2645.txt", + key="RFC 2645", + abstract={This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]}, + keywords="ODMR-SMTP, simple mail, transfer, protocol, internet", + doi="10.17487/RFC2645", + } + +@misc{rfc2646, + author="R. {Gellens (Ed.)}", + title="{The Text/Plain Format Parameter}", + howpublished="RFC 2646 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2646", + pages="1--14", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3676", +url="https://www.rfc-editor.org/rfc/rfc2646.txt", + key="RFC 2646", + abstract={This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]}, + keywords="media type, mime, multipurpose, internet, mail, extension", + doi="10.17487/RFC2646", + } + +@misc{rfc2647, + author="D. Newman", + title="{Benchmarking Terminology for Firewall Performance}", + howpublished="RFC 2647 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2647", + pages="1--26", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2647.txt", + key="RFC 2647", + abstract={This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]}, + keywords="routers, switches, measurement", + doi="10.17487/RFC2647", + } + +@misc{rfc2648, + author="R. Moats", + title="{A URN Namespace for IETF Documents}", + howpublished="RFC 2648 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2648", + pages="1--30", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6924", +url="https://www.rfc-editor.org/rfc/rfc2648.txt", + key="RFC 2648", + abstract={This document proposes the ``ietf'' namespace, which consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor and the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences. [STANDARDS-TRACK]}, + keywords="uniform, resource, names, internet, engineering, task, force", + doi="10.17487/RFC2648", + } + +@misc{rfc2649, + author="B. Greenblatt and P. Richard", + title="{An LDAP Control and Schema for Holding Operation Signatures}", + howpublished="RFC 2649 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2649", + pages="1--10", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2649.txt", + key="RFC 2649", + abstract={This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. This memo defines an Experimental Protocol for the Internet community.}, + keywords="lightweight, directory, access protocol, client, server", + doi="10.17487/RFC2649", + } + +@misc{rfc2650, + author="D. Meyer and J. Schmitz and C. Orange and M. Prior and C. Alaettinoglu", + title="{Using RPSL in Practice}", + howpublished="RFC 2650 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2650", + pages="1--26", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2650.txt", + key="RFC 2650", + abstract={This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). This memo provides information for the Internet community.}, + keywords="routing policy, specification language, IRR, internet routing, registry, configurations", + doi="10.17487/RFC2650", + } + +@misc{rfc2651, + author="J. Allen and M. Mealling", + title="{The Architecture of the Common Indexing Protocol (CIP)}", + howpublished="RFC 2651 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2651", + pages="1--19", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2651.txt", + key="RFC 2651", + abstract={This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK]}, + keywords="CIP, query, routing, database, servers", + doi="10.17487/RFC2651", + } + +@misc{rfc2652, + author="J. Allen and M. Mealling", + title="{MIME Object Definitions for the Common Indexing Protocol (CIP)}", + howpublished="RFC 2652 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2652", + pages="1--22", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2652.txt", + key="RFC 2652", + abstract={This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK]}, + keywords="multipurpose, internet, mail, extensions, database", + doi="10.17487/RFC2652", + } + +@misc{rfc2653, + author="J. Allen and P. Leach and R. Hedberg", + title="{CIP Transport Protocols}", + howpublished="RFC 2653 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2653", + pages="1--11", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2653.txt", + key="RFC 2653", + abstract={This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK]}, + keywords="common indexing, message, formats", + doi="10.17487/RFC2653", + } + +@misc{rfc2654, + author="R. Hedberg and B. Greenblatt and R. Moats and M. Wahl", + title="{A Tagged Index Object for use in the Common Indexing Protocol}", + howpublished="RFC 2654 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2654", + pages="1--24", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2654.txt", + key="RFC 2654", + abstract={This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. This memo defines an Experimental Protocol for the Internet community.}, + keywords="CIP, information, servers, database", + doi="10.17487/RFC2654", + } + +@misc{rfc2655, + author="T. Hardie and M. Bowman and D. Hardy and M. Schwartz and D. Wessels", + title="{CIP Index Object Format for SOIF Objects}", + howpublished="RFC 2655 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2655", + pages="1--17", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2655.txt", + key="RFC 2655", + abstract={This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community.}, + keywords="summary, object, interchange, format, common, indexing, protocol", + doi="10.17487/RFC2655", + } + +@misc{rfc2656, + author="T. Hardie", + title="{Registration Procedures for SOIF Template Types}", + howpublished="RFC 2656 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2656", + pages="1--9", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2656.txt", + key="RFC 2656", + abstract={The registration procedure described in this document is specific to SOIF template types. This memo defines an Experimental Protocol for the Internet community.}, + keywords="summary, object, interchange, format, stream", + doi="10.17487/RFC2656", + } + +@misc{rfc2657, + author="R. Hedberg", + title="{LDAPv2 Client vs. the Index Mesh}", + howpublished="RFC 2657 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2657", + pages="1--12", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2657.txt", + key="RFC 2657", + abstract={LDAPv2 clients as implemented according to RFC 1777 have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. This memo defines an Experimental Protocol for the Internet community.}, + keywords="lightweight, directory, access, protocol, CIP, common, indexing", + doi="10.17487/RFC2657", + } + +@misc{rfc2658, + author="K. McKay", + title="{RTP Payload Format for PureVoice(tm) Audio}", + howpublished="RFC 2658 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2658", + pages="1--10", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2658.txt", + key="RFC 2658", + abstract={This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]}, + keywords="real-time, transport, protocol, packet, end-to-end", + doi="10.17487/RFC2658", + } + +@misc{rfc2659, + author="E. Rescorla and A. Schiffman", + title="{Security Extensions For HTML}", + howpublished="RFC 2659 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2659", + pages="1--4", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2659.txt", + key="RFC 2659", + abstract={This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. This memo defines an Experimental Protocol for the Internet community.}, + keywords="hyper-text, markup language, cryptology", + doi="10.17487/RFC2659", + } + +@misc{rfc2660, + author="E. Rescorla and A. Schiffman", + title="{The Secure HyperText Transfer Protocol}", + howpublished="RFC 2660 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2660", + pages="1--45", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2660.txt", + key="RFC 2660", + abstract={This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. This memo defines an Experimental Protocol for the Internet community.}, + keywords="WWW, world wide web, http, authentication", + doi="10.17487/RFC2660", + } + +@misc{rfc2661, + author="W. Townsley and A. Valencia and A. Rubens and G. Pall and G. Zorn and B. Palter", + title="{Layer Two Tunneling Protocol ``L2TP''}", + howpublished="RFC 2661 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2661", + pages="1--80", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2661.txt", + key="RFC 2661", + abstract={This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]}, + keywords="L2TP, ppp, point-to-point, protocol, packets", + doi="10.17487/RFC2661", + } + +@misc{rfc2662, + author="G. Bathrick and F. Ly", + title="{Definitions of Managed Objects for the ADSL Lines}", + howpublished="RFC 2662 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2662", + pages="1--115", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2662.txt", + key="RFC 2662", + abstract={This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]}, + keywords="MIB, management information, base", + doi="10.17487/RFC2662", + } + +@misc{rfc2663, + author="P. Srisuresh and M. Holdrege", + title="{IP Network Address Translator (NAT) Terminology and Considerations}", + howpublished="RFC 2663 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2663", + pages="1--30", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2663.txt", + key="RFC 2663", + abstract={This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community.}, + keywords="network address, translator, IP, internet protocol, addresses", + doi="10.17487/RFC2663", + } + +@misc{rfc2664, + author="R. Plzak and A. Wells and E. Krol", + title="{FYI on Questions and Answers - Answers to Commonly Asked ``New Internet User'' Questions}", + howpublished="RFC 2664 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2664", + pages="1--11", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2664.txt", + key="RFC 2664", + abstract={This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. This memo provides information for the Internet community.}, + keywords="documentation, help, information, FAQ", + doi="10.17487/RFC2664", + } + +@misc{rfc2665, + author="J. Flick and J. Johnson", + title="{Definitions of Managed Objects for the Ethernet-like Interface Types}", + howpublished="RFC 2665 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2665", + pages="1--47", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3635", +url="https://www.rfc-editor.org/rfc/rfc2665.txt", + key="RFC 2665", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]}, + keywords="MIB, management, information, base", + doi="10.17487/RFC2665", + } + +@misc{rfc2666, + author="J. Flick", + title="{Definitions of Object Identifiers for Identifying Ethernet Chip Sets}", + howpublished="RFC 2666 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2666", + pages="1--18", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2666.txt", + key="RFC 2666", + abstract={This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. This memo provides information for the Internet community.}, + keywords="mib, management, information, base", + doi="10.17487/RFC2666", + } + +@misc{rfc2667, + author="D. Thaler", + title="{IP Tunnel MIB}", + howpublished="RFC 2667 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2667", + pages="1--16", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4087", +url="https://www.rfc-editor.org/rfc/rfc2667.txt", + key="RFC 2667", + abstract={This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]}, + keywords="internet, protocol, management, information, base", + doi="10.17487/RFC2667", + } + +@misc{rfc2668, + author="A. Smith and J. Flick and K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie and S. Roberts", + title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}", + howpublished="RFC 2668 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2668", + pages="1--56", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3636", +url="https://www.rfc-editor.org/rfc/rfc2668.txt", + key="RFC 2668", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]}, + keywords="MAU-MIB, management, information, base", + doi="10.17487/RFC2668", + } + +@misc{rfc2669, + author="M. St. {Johns (Ed.)}", + title="{DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems}", + howpublished="RFC 2669 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2669", + pages="1--55", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4639", +url="https://www.rfc-editor.org/rfc/rfc2669.txt", + key="RFC 2669", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2669", + } + +@misc{rfc2670, + author="M. St. {Johns (Ed.)}", + title="{Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces}", + howpublished="RFC 2670 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2670", + pages="1--72", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4546", +url="https://www.rfc-editor.org/rfc/rfc2670.txt", + key="RFC 2670", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. [STANDARDS-TRACK]}, + keywords="MIB", + doi="10.17487/RFC2670", + } + +@misc{rfc2671, + author="P. Vixie", + title="{Extension Mechanisms for DNS (EDNS0)}", + howpublished="RFC 2671 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2671", + pages="1--7", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6891", +url="https://www.rfc-editor.org/rfc/rfc2671.txt", + key="RFC 2671", + abstract={The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]}, + keywords="EDNS0, domain, name, system, resource, records, opt", + doi="10.17487/RFC2671", + } + +@misc{rfc2672, + author="M. Crawford", + title="{Non-Terminal DNS Name Redirection}", + howpublished="RFC 2672 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2672", + pages="1--9", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6672, updated by RFCs 4592, 6604", +url="https://www.rfc-editor.org/rfc/rfc2672.txt", + key="RFC 2672", + abstract={This document defines a new DNS Resource Record called ``DNAME'', which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]}, + keywords="domain, name, system, dname, resource, records", + doi="10.17487/RFC2672", + } + +@misc{rfc2673, + author="M. Crawford", + title="{Binary Labels in the Domain Name System}", + howpublished="RFC 2673 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2673", + pages="1--7", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6891, updated by RFCs 3363, 3364", +url="https://www.rfc-editor.org/rfc/rfc2673.txt", + key="RFC 2673", + abstract={This document defines a ``Bit-String Label'' which may appear within domain names. This new label type compactly represents a sequence of ``One-Bit Labels'' and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]}, + keywords="DNS, data", + doi="10.17487/RFC2673", + } + +@misc{rfc2674, + author="E. Bell and A. Smith and P. Langille and A. Rijhsinghani and K. McCloghrie", + title="{Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions}", + howpublished="RFC 2674 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2674", + pages="1--86", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4363", +url="https://www.rfc-editor.org/rfc/rfc2674.txt", + key="RFC 2674", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK]}, + keywords="MIB, management, information, base, local, area, network", + doi="10.17487/RFC2674", + } + +@misc{rfc2675, + author="D. Borman and S. Deering and R. Hinden", + title="{IPv6 Jumbograms}", + howpublished="RFC 2675 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2675", + pages="1--9", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2675.txt", + key="RFC 2675", + abstract={This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]}, + keywords="internet, protocol, packet, payload, link", + doi="10.17487/RFC2675", + } + +@misc{rfc2676, + author="G. Apostolopoulos and S. Kama and D. Williams and R. Guerin and A. Orda and T. Przygienda", + title="{QoS Routing Mechanisms and OSPF Extensions}", + howpublished="RFC 2676 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2676", + pages="1--50", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2676.txt", + key="RFC 2676", + abstract={This memo describes extensions to the OSPF protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. This memo defines an Experimental Protocol for the Internet community.}, + keywords="quality of service, open shortest, path first, routing", + doi="10.17487/RFC2676", + } + +@misc{rfc2677, + author="M. Greene and J. Cucchiara and J. Luciani", + title="{Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)}", + howpublished="RFC 2677 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2677", + pages="1--67", + year=1999, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2677.txt", + key="RFC 2677", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]}, + keywords="NHRP-MIB, management, information, base", + doi="10.17487/RFC2677", + } + +@misc{rfc2678, + author="J. Mahdavi and V. Paxson", + title="{IPPM Metrics for Measuring Connectivity}", + howpublished="RFC 2678 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2678", + pages="1--10", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2678.txt", + key="RFC 2678", + abstract={This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]}, + keywords="IPPM-MET, internet, protocol, performance, metrics", + doi="10.17487/RFC2678", + } + +@misc{rfc2679, + author="G. Almes and S. Kalidindi and M. Zekauskas", + title="{A One-way Delay Metric for IPPM}", + howpublished="RFC 2679 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2679", + pages="1--20", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7679", +url="https://www.rfc-editor.org/rfc/rfc2679.txt", + key="RFC 2679", + abstract={This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]}, + keywords="internet, protocol, performance, metrics, packets", + doi="10.17487/RFC2679", + } + +@misc{rfc2680, + author="G. Almes and S. Kalidindi and M. Zekauskas", + title="{A One-way Packet Loss Metric for IPPM}", + howpublished="RFC 2680 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2680", + pages="1--15", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7680", +url="https://www.rfc-editor.org/rfc/rfc2680.txt", + key="RFC 2680", + abstract={This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]}, + keywords="internet, protocol, performance, metrics", + doi="10.17487/RFC2680", + } + +@misc{rfc2681, + author="G. Almes and S. Kalidindi and M. Zekauskas", + title="{A Round-trip Delay Metric for IPPM}", + howpublished="RFC 2681 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2681", + pages="1--20", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2681.txt", + key="RFC 2681", + abstract={This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]}, + keywords="internet, protocol, performance, metrics, packets", + doi="10.17487/RFC2681", + } + +@misc{rfc2682, + author="I. Widjaja and A. Elwalid", + title="{Performance Issues in VC-Merge Capable ATM LSRs}", + howpublished="RFC 2682 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2682", + pages="1--12", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2682.txt", + key="RFC 2682", + abstract={This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. This memo provides information for the Internet community.}, + keywords="asynchronous, transfer mode, routing", + doi="10.17487/RFC2682", + } + +@misc{rfc2683, + author="B. Leiba", + title="{IMAP4 Implementation Recommendations}", + howpublished="RFC 2683 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2683", + pages="1--23", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7162", +url="https://www.rfc-editor.org/rfc/rfc2683.txt", + key="RFC 2683", + abstract={The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.}, + keywords="internet, message, access, protocol, clients, servers", + doi="10.17487/RFC2683", + } + +@misc{rfc2684, + author="D. Grossman and J. Heinanen", + title="{Multiprotocol Encapsulation over ATM Adaptation Layer 5}", + howpublished="RFC 2684 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2684", + pages="1--23", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2684.txt", + key="RFC 2684", + abstract={This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK]}, + keywords="asynchronous,transfer, mode, multiplexing", + doi="10.17487/RFC2684", + } + +@misc{rfc2685, + author="B. Fox and B. Gleeson", + title="{Virtual Private Networks Identifier}", + howpublished="RFC 2685 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2685", + pages="1--6", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2685.txt", + key="RFC 2685", + abstract={This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK]}, + keywords="VPNI, IP, internet, protocol, VPN", + doi="10.17487/RFC2685", + } + +@misc{rfc2686, + author="C. Bormann", + title="{The Multi-Class Extension to Multi-Link PPP}", + howpublished="RFC 2686 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2686", + pages="1--11", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2686.txt", + key="RFC 2686", + abstract={This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]}, + keywords="point-to-point protocol, encapsulation", + doi="10.17487/RFC2686", + } + +@misc{rfc2687, + author="C. Bormann", + title="{PPP in a Real-time Oriented HDLC-like Framing}", + howpublished="RFC 2687 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2687", + pages="1--13", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2687.txt", + key="RFC 2687", + abstract={This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]}, + keywords="point-to-point protocol, encapsulation, high-level, data link, control", + doi="10.17487/RFC2687", + } + +@misc{rfc2688, + author="S. Jackowski and D. Putzolu and E. Crawley and B. Davie", + title="{Integrated Services Mappings for Low Speed Networks}", + howpublished="RFC 2688 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2688", + pages="1--16", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2688.txt", + key="RFC 2688", + abstract={This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK]}, + keywords="controlled, load, guaranteed, services", + doi="10.17487/RFC2688", + } + +@misc{rfc2689, + author="C. Bormann", + title="{Providing Integrated Services over Low-bitrate Links}", + howpublished="RFC 2689 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2689", + pages="1--14", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2689.txt", + key="RFC 2689", + abstract={This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. This memo provides information for the Internet community.}, + keywords="asynchronous, synchronous, real-time", + doi="10.17487/RFC2689", + } + +@misc{rfc2690, + author="S. Bradner", + title="{A Proposal for an MOU-Based ICANN Protocol Support Organization}", + howpublished="RFC 2690 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2690", + pages="1--8", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2690.txt", + key="RFC 2690", + abstract={This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community.}, + keywords="pso, memorandum of understanding, internet, corporation for assigned names and numbers", + doi="10.17487/RFC2690", + } + +@misc{rfc2691, + author="S. Bradner", + title="{A Memorandum of Understanding for an ICANN Protocol Support Organization}", + howpublished="RFC 2691 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2691", + pages="1--9", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2691.txt", + key="RFC 2691", + abstract={This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers (ICANN). This memo provides information for the Internet community.}, + keywords="mou, pso, internet, corporation for assigned names and numbers", + doi="10.17487/RFC2691", + } + +@misc{rfc2692, + author="C. Ellison", + title="{SPKI Requirements}", + howpublished="RFC 2692 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2692", + pages="1--14", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2692.txt", + key="RFC 2692", + abstract={The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SPKI, simple public, key, infrastructure, authentication", + doi="10.17487/RFC2692", + } + +@misc{rfc2693, + author="C. Ellison and B. Frantz and B. Lampson and R. Rivest and B. Thomas and T. Ylonen", + title="{SPKI Certificate Theory}", + howpublished="RFC 2693 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2693", + pages="1--43", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2693.txt", + key="RFC 2693", + abstract={This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SPKI, simple, public, key, infrastructure, authentication", + doi="10.17487/RFC2693", + } + +@misc{rfc2694, + author="P. Srisuresh and G. Tsirtsis and P. Akkiraju and A. Heffernan", + title="{DNS extensions to Network Address Translators (DNS\_ALG)}", + howpublished="RFC 2694 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2694", + pages="1--29", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2694.txt", + key="RFC 2694", + abstract={This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS\_ALG) can meet the need. This memo provides information for the Internet community.}, + keywords="domain name, system, NATs, mapping", + doi="10.17487/RFC2694", + } + +@misc{rfc2695, + author="A. Chiu", + title="{Authentication Mechanisms for ONC RPC}", + howpublished="RFC 2695 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2695", + pages="1--18", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2695.txt", + key="RFC 2695", + abstract={This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community.}, + keywords="remote procedure, call, open network, computing", + doi="10.17487/RFC2695", + } + +@misc{rfc2696, + author="C. Weider and A. Herron and A. Anantha and T. Howes", + title="{LDAP Control Extension for Simple Paged Results Manipulation}", + howpublished="RFC 2696 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2696", + pages="1--7", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2696.txt", + key="RFC 2696", + abstract={This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol, client, server", + doi="10.17487/RFC2696", + } + +@misc{rfc2697, + author="J. Heinanen and R. Guerin", + title="{A Single Rate Three Color Marker}", + howpublished="RFC 2697 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2697", + pages="1--6", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2697.txt", + key="RFC 2697", + abstract={This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community.}, + keywords="srtcm, stream, ip, internet, protocol, packet", + doi="10.17487/RFC2697", + } + +@misc{rfc2698, + author="J. Heinanen and R. Guerin", + title="{A Two Rate Three Color Marker}", + howpublished="RFC 2698 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2698", + pages="1--5", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2698.txt", + key="RFC 2698", + abstract={This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community.}, + keywords="trTCM, stream, ip, internet, protocol, packet", + doi="10.17487/RFC2698", + } + +@misc{rfc2699, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 2600-2699}", + howpublished="RFC 2699 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2699", + pages="1--22", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2699.txt", + key="RFC 2699", + doi="10.17487/RFC2699", + } + +@misc{rfc2700, + author="J. Reynolds and R. Braden", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2700 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2700", + pages="1--32", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2800", +url="https://www.rfc-editor.org/rfc/rfc2700.txt", + key="RFC 2700", + abstract={This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS-TRACK]}, + doi="10.17487/RFC2700", + } + +@misc{rfc2701, + author="G. Malkin", + title="{Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol}", + howpublished="RFC 2701 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2701", + pages="1--9", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2701.txt", + key="RFC 2701", + abstract={This document specifies a standard way for Multi-link PPP to operate across multiple nodes. This memo provides information for the Internet community.}, + keywords="point-to-point, POP, presence, RAS, remote access, server", + doi="10.17487/RFC2701", + } + +@misc{rfc2702, + author="D. Awduche and J. Malcolm and J. Agogbua and M. O'Dell and J. McManus", + title="{Requirements for Traffic Engineering Over MPLS}", + howpublished="RFC 2702 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2702", + pages="1--29", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2702.txt", + key="RFC 2702", + abstract={This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community.}, + keywords="multiprotocol, label, switching", + doi="10.17487/RFC2702", + } + +@misc{rfc2703, + author="G. Klyne", + title="{Protocol-independent Content Negotiation Framework}", + howpublished="RFC 2703 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2703", + pages="1--20", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2703.txt", + key="RFC 2703", + abstract={This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. This memo provides information for the Internet community.}, + keywords="feature, resource, media, syntax", + doi="10.17487/RFC2703", + } + +@misc{rfc2704, + author="M. Blaze and J. Feigenbaum and J. Ioannidis and A. Keromytis", + title="{The KeyNote Trust-Management System Version 2}", + howpublished="RFC 2704 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2704", + pages="1--37", + year=1999, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2704.txt", + key="RFC 2704", + abstract={This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. This memo provides information for the Internet community.}, + keywords="security, policy maker, system, credentials", + doi="10.17487/RFC2704", + } + +@misc{rfc2705, + author="M. Arango and A. Dugan and I. Elliott and C. Huitema and S. Pickett", + title="{Media Gateway Control Protocol (MGCP) Version 1.0}", + howpublished="RFC 2705 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2705", + pages="1--134", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3435, updated by RFC 3660", +url="https://www.rfc-editor.org/rfc/rfc2705.txt", + key="RFC 2705", + abstract={This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control ``intelligence'' is outside the gateways and handled by external call control elements. This memo provides information for the Internet community.}, + keywords="voice, IP, internet, VoIP", + doi="10.17487/RFC2705", + } + +@misc{rfc2706, + author="D. {Eastlake 3rd} and T. Goldstein", + title="{ECML v1: Field Names for E-Commerce}", + howpublished="RFC 2706 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2706", + pages="1--13", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3106", +url="https://www.rfc-editor.org/rfc/rfc2706.txt", + key="RFC 2706", + abstract={A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. This memo provides information for the Internet community.}, + keywords="electronic, commerce, modeling, language, merchant, site. web", + doi="10.17487/RFC2706", + } + +@misc{rfc2707, + author="R. Bergman and T. Hastings and S. Isaacson and H. Lewis", + title="{Job Monitoring MIB - V1.0}", + howpublished="RFC 2707 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2707", + pages="1--114", + year=1999, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2707.txt", + key="RFC 2707", + abstract={This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This memo provides information for the Internet community.}, + keywords="management, information, base", + doi="10.17487/RFC2707", + } + +@misc{rfc2708, + author="R. Bergman", + title="{Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB}", + howpublished="RFC 2708 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2708", + pages="1--26", + year=1999, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2708.txt", + key="RFC 2708", + abstract={This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. This memo provides information for the Internet community.}, + keywords="management, information, base", + doi="10.17487/RFC2708", + } + +@misc{rfc2709, + author="P. Srisuresh", + title="{Security Model with Tunnel-mode IPsec for NAT Domains}", + howpublished="RFC 2709 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2709", + pages="1--11", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2709.txt", + key="RFC 2709", + abstract={This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. This memo provides information for the Internet community.}, + keywords="internet protocol, network address, translator", + doi="10.17487/RFC2709", + } + +@misc{rfc2710, + author="S. Deering and W. Fenner and B. Haberman", + title="{Multicast Listener Discovery (MLD) for IPv6}", + howpublished="RFC 2710 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2710", + pages="1--22", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3590, 3810", +url="https://www.rfc-editor.org/rfc/rfc2710.txt", + key="RFC 2710", + abstract={This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]}, + keywords="MLD-IPv6, internet protocol, routher, packets", + doi="10.17487/RFC2710", + } + +@misc{rfc2711, + author="C. Partridge and A. Jackson", + title="{IPv6 Router Alert Option}", + howpublished="RFC 2711 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2711", + pages="1--6", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6398", +url="https://www.rfc-editor.org/rfc/rfc2711.txt", + key="RFC 2711", + abstract={This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]}, + keywords="internet protocol, datagram, routher, hop-by-hop", + doi="10.17487/RFC2711", + } + +@misc{rfc2712, + author="A. Medvinsky and M. Hur", + title="{Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)}", + howpublished="RFC 2712 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2712", + pages="1--7", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2712.txt", + key="RFC 2712", + abstract={This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS-TRACK]}, + keywords="TLS, authentication, cryptography", + doi="10.17487/RFC2712", + } + +@misc{rfc2713, + author="V. Ryan and S. Seligman and R. Lee", + title="{Schema for Representing Java(tm) Objects in an LDAP Directory}", + howpublished="RFC 2713 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2713", + pages="1--21", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2713.txt", + key="RFC 2713", + abstract={This document defines the schema for representing Java(tm) objects in an LDAP directory. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol", + doi="10.17487/RFC2713", + } + +@misc{rfc2714, + author="V. Ryan and R. Lee and S. Seligman", + title="{Schema for Representing CORBA Object References in an LDAP Directory}", + howpublished="RFC 2714 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2714", + pages="1--10", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2714.txt", + key="RFC 2714", + abstract={This document defines the schema for representing CORBA object references in an LDAP directory. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol", + doi="10.17487/RFC2714", + } + +@misc{rfc2715, + author="D. Thaler", + title="{Interoperability Rules for Multicast Routing Protocols}", + howpublished="RFC 2715 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2715", + pages="1--22", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2715.txt", + key="RFC 2715", + abstract={The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. This memo provides information for the Internet community.}, + keywords="border, router, MBRs, autonomous", + doi="10.17487/RFC2715", + } + +@misc{rfc2716, + author="B. Aboba and D. Simon", + title="{PPP EAP TLS Authentication Protocol}", + howpublished="RFC 2716 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2716", + pages="1--24", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5216", +url="https://www.rfc-editor.org/rfc/rfc2716.txt", + key="RFC 2716", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.}, + keywords="point-to-point, link control compression, extensible, transport level security", + doi="10.17487/RFC2716", + } + +@misc{rfc2717, + author="R. Petke and I. King", + title="{Registration Procedures for URL Scheme Names}", + howpublished="RFC 2717 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2717", + pages="1--10", + year=1999, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4395", +url="https://www.rfc-editor.org/rfc/rfc2717.txt", + key="RFC 2717", + abstract={This document defines the process by which new URL scheme names are registered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="uniform, resource, locator, syntax, semantics", + doi="10.17487/RFC2717", + } + +@misc{rfc2718, + author="L. Masinter and H. Alvestrand and D. Zigmond and R. Petke", + title="{Guidelines for new URL Schemes}", + howpublished="RFC 2718 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2718", + pages="1--10", + year=1999, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4395", +url="https://www.rfc-editor.org/rfc/rfc2718.txt", + key="RFC 2718", + abstract={This document provides guidelines for the definition of new URL schemes. This memo provides information for the Internet community.}, + keywords="uniform, resource, locator, syntax, semantics", + doi="10.17487/RFC2718", + } + +@misc{rfc2719, + author="L. Ong and I. Rytina and M. Garcia and H. Schwarzbauer and L. Coene and H. Lin and I. Juhasz and M. Holdrege and C. Sharp", + title="{Framework Architecture for Signaling Transport}", + howpublished="RFC 2719 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2719", + pages="1--24", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2719.txt", + key="RFC 2719", + abstract={This document defines an architecture framework and functional requirements for transport of signaling information over IP. This memo provides information for the Internet community.}, + keywords="IP, Internet Protocol, gateway, media, circuit", + doi="10.17487/RFC2719", + } + +@misc{rfc2720, + author="N. Brownlee", + title="{Traffic Flow Measurement: Meter MIB}", + howpublished="RFC 2720 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2720", + pages="1--55", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2720.txt", + key="RFC 2720", + abstract={This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2720", + } + +@misc{rfc2721, + author="N. Brownlee", + title="{RTFM: Applicability Statement}", + howpublished="RFC 2721 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2721", + pages="1--10", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2721.txt", + key="RFC 2721", + abstract={This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. This memo provides information for the Internet community.}, + keywords="real-time, traffic flow, measurement", + doi="10.17487/RFC2721", + } + +@misc{rfc2722, + author="N. Brownlee and C. Mills and G. Ruth", + title="{Traffic Flow Measurement: Architecture}", + howpublished="RFC 2722 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2722", + pages="1--48", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2722.txt", + key="RFC 2722", + abstract={This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. This memo provides information for the Internet community.}, + keywords="network, meters, data", + doi="10.17487/RFC2722", + } + +@misc{rfc2723, + author="N. Brownlee", + title="{SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups}", + howpublished="RFC 2723 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2723", + pages="1--22", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2723.txt", + key="RFC 2723", + abstract={This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. This memo provides information for the Internet community.}, + keywords="simple, ruleset, RTFM, real-time, network, measurement", + doi="10.17487/RFC2723", + } + +@misc{rfc2724, + author="S. Handelman and S. Stibler and N. Brownlee and G. Ruth", + title="{RTFM: New Attributes for Traffic Flow Measurement}", + howpublished="RFC 2724 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2724", + pages="1--18", + year=1999, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2724.txt", + key="RFC 2724", + abstract={This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. This memo defines an Experimental Protocol for the Internet community.}, + keywords="real-time, network", + doi="10.17487/RFC2724", + } + +@misc{rfc2725, + author="C. Villamizar and C. Alaettinoglu and D. Meyer and S. Murphy", + title="{Routing Policy System Security}", + howpublished="RFC 2725 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2725", + pages="1--41", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4012", +url="https://www.rfc-editor.org/rfc/rfc2725.txt", + key="RFC 2725", + abstract={The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. [STANDARDS-TRACK]}, + keywords="RPSL, database, registry, authentication", + doi="10.17487/RFC2725", + } + +@misc{rfc2726, + author="J. Zsako", + title="{PGP Authentication for RIPE Database Updates}", + howpublished="RFC 2726 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2726", + pages="1--11", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2726.txt", + key="RFC 2726", + abstract={This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS-TRACK]}, + keywords="pretty good, privacy, security, digital, signatures", + doi="10.17487/RFC2726", + } + +@misc{rfc2727, + author="J. Galvin", + title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}", + howpublished="RFC 2727 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2727", + pages="1--15", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3777", +url="https://www.rfc-editor.org/rfc/rfc2727.txt", + key="RFC 2727", + abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet, Architecture, Board, Engineering, Steering, Group", + doi="10.17487/RFC2727", + } + +@misc{rfc2728, + author="R. Panabaker and S. Wegerif and D. Zigmond", + title="{The Transmission of IP Over the Vertical Blanking Interval of a Television Signal}", + howpublished="RFC 2728 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2728", + pages="1--23", + year=1999, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2728.txt", + key="RFC 2728", + abstract={This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS-TRACK]}, + keywords="internet, protocol, IPVBI", + doi="10.17487/RFC2728", + } + +@misc{rfc2729, + author="P. Bagnall and R. Briscoe and A. Poppitt", + title="{Taxonomy of Communication Requirements for Large-scale Multicast Applications}", + howpublished="RFC 2729 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2729", + pages="1--27", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2729.txt", + key="RFC 2729", + abstract={The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). This memo provides information for the Internet community.}, + keywords="LSMA, dynamic, protocol, mapping", + doi="10.17487/RFC2729", + } + +@misc{rfc2730, + author="S. Hanna and B. Patel and M. Shah", + title="{Multicast Address Dynamic Client Allocation Protocol (MADCAP)}", + howpublished="RFC 2730 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2730", + pages="1--53", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2730.txt", + key="RFC 2730", + abstract={This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK]}, + keywords="MADCAP, client, server, scope, zone, host", + doi="10.17487/RFC2730", + } + +@misc{rfc2731, + author="J. Kunze", + title="{Encoding Dublin Core Metadata in HTML}", + howpublished="RFC 2731 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2731", + pages="1--23", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5791", +url="https://www.rfc-editor.org/rfc/rfc2731.txt", + key="RFC 2731", + abstract={The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.}, + keywords="hypertext, markup, language, xml, extensible", + doi="10.17487/RFC2731", + } + +@misc{rfc2732, + author="R. Hinden and B. Carpenter and L. Masinter", + title="{Format for Literal IPv6 Addresses in URL's}", + howpublished="RFC 2732 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2732", + pages="1--5", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3986", +url="https://www.rfc-editor.org/rfc/rfc2732.txt", + key="RFC 2732", + abstract={This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK]}, + keywords="Internet, protocol, uniform, resource, identifier, www, world wide web", + doi="10.17487/RFC2732", + } + +@misc{rfc2733, + author="J. Rosenberg and H. Schulzrinne", + title="{An RTP Payload Format for Generic Forward Error Correction}", + howpublished="RFC 2733 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2733", + pages="1--26", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5109", +url="https://www.rfc-editor.org/rfc/rfc2733.txt", + key="RFC 2733", + abstract={This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS-TRACK]}, + keywords="FEC, real-time, protocol, stream", + doi="10.17487/RFC2733", + } + +@misc{rfc2734, + author="P. Johansson", + title="{IPv4 over IEEE 1394}", + howpublished="RFC 2734 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2734", + pages="1--29", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2734.txt", + key="RFC 2734", + abstract={This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS-TRACK]}, + keywords="internet, protocol, datagrams, packet, encapsulation, ARP, address, resolution, multicast", + doi="10.17487/RFC2734", + } + +@misc{rfc2735, + author="B. Fox and B. Petri", + title="{NHRP Support for Virtual Private Networks}", + howpublished="RFC 2735 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2735", + pages="1--12", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2735.txt", + key="RFC 2735", + abstract={The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the ``NBMA next hop'' towards a public internetworking layer address. This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. [STANDARDS-TRACK]}, + keywords="next hop, resolution, protocol, VPN, addresses", + doi="10.17487/RFC2735", + } + +@misc{rfc2736, + author="M. Handley and C. Perkins", + title="{Guidelines for Writers of RTP Payload Format Specifications}", + howpublished="RFC 2736 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2736", + pages="1--10", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8088", +url="https://www.rfc-editor.org/rfc/rfc2736.txt", + key="RFC 2736", + abstract={This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="real-time, transport, protocol, data types, audio, video, codecs", + doi="10.17487/RFC2736", + } + +@misc{rfc2737, + author="K. McCloghrie and A. Bierman", + title="{Entity MIB (Version 2)}", + howpublished="RFC 2737 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2737", + pages="1--56", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4133", +url="https://www.rfc-editor.org/rfc/rfc2737.txt", + key="RFC 2737", + abstract={This memo defines a portion of the Management Information Base (M for use with network management protocols in the Internet communi In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]}, + keywords="management, information, base, SNMP, simple, network, protocol", + doi="10.17487/RFC2737", + } + +@misc{rfc2738, + author="G. Klyne", + title="{Corrections to ``A Syntax for Describing Media Feature Sets''}", + howpublished="RFC 2738 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2738", + pages="1--5", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2738.txt", + key="RFC 2738", + abstract={In RFC 2533, ``A Syntax for Describing Media Feature Sets'', an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. [STANDARDS-TRACK]}, + keywords="FEC, real-time, protocol, stream", + doi="10.17487/RFC2738", + } + +@misc{rfc2739, + author="T. Small and D. Hennessy and F. Dawson", + title="{Calendar Attributes for vCard and LDAP}", + howpublished="RFC 2739 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2739", + pages="1--16", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6350", +url="https://www.rfc-editor.org/rfc/rfc2739.txt", + key="RFC 2739", + abstract={This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol", + doi="10.17487/RFC2739", + } + +@misc{rfc2740, + author="R. Coltun and D. Ferguson and J. Moy", + title="{OSPF for IPv6}", + howpublished="RFC 2740 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2740", + pages="1--80", + year=1999, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5340", +url="https://www.rfc-editor.org/rfc/rfc2740.txt", + key="RFC 2740", + abstract={This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]}, + keywords="internet, protocol, open shortest, path first", + doi="10.17487/RFC2740", + } + +@misc{rfc2741, + author="M. Daniele and B. Wijnen and M. Ellison and D. Francisco", + title="{Agent Extensibility (AgentX) Protocol Version 1}", + howpublished="RFC 2741 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2741", + pages="1--91", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2741.txt", + key="RFC 2741", + abstract={This memo defines a standardized framework for extensible SNMP agents. [STANDARDS-TRACK]}, + keywords="SNMP, simple, network, management", + doi="10.17487/RFC2741", + } + +@misc{rfc2742, + author="L. Heintz and S. Gudur and M. Ellison", + title="{Definitions of Managed Objects for Extensible SNMP Agents}", + howpublished="RFC 2742 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2742", + pages="1--20", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2742.txt", + key="RFC 2742", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. [STANDARDS-TRACK]}, + keywords="SNMP, management, information, base, simple, network, protocol", + doi="10.17487/RFC2742", + } + +@misc{rfc2743, + author="J. Linn", + title="{Generic Security Service Application Program Interface Version 2, Update 1}", + howpublished="RFC 2743 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2743", + pages="1--101", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5554", +url="https://www.rfc-editor.org/rfc/rfc2743.txt", + key="RFC 2743", + abstract={This memo obsoletes [STANDARDS-TRACK]}, + keywords="GSS-API, portability, application, authentication, cryptology", + doi="10.17487/RFC2743", + } + +@misc{rfc2744, + author="J. Wray", + title="{Generic Security Service API Version 2 : C-bindings}", + howpublished="RFC 2744 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2744", + pages="1--101", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2744.txt", + key="RFC 2744", + abstract={This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC 2743. [STANDARDS-TRACK]}, + keywords="GSS-API, cryptology, authentication", + doi="10.17487/RFC2744", + } + +@misc{rfc2745, + author="A. Terzis and B. Braden and S. Vincent and L. Zhang", + title="{RSVP Diagnostic Messages}", + howpublished="RFC 2745 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2745", + pages="1--23", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2745.txt", + key="RFC 2745", + abstract={This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, network, management", + doi="10.17487/RFC2745", + } + +@misc{rfc2746, + author="A. Terzis and J. Krawczyk and J. Wroclawski and L. Zhang", + title="{RSVP Operation Over IP Tunnels}", + howpublished="RFC 2746 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2746", + pages="1--25", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2746.txt", + key="RFC 2746", + abstract={This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, internet", + doi="10.17487/RFC2746", + } + +@misc{rfc2747, + author="F. Baker and B. Lindell and M. Talwar", + title="{RSVP Cryptographic Authentication}", + howpublished="RFC 2747 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2747", + pages="1--21", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3097", +url="https://www.rfc-editor.org/rfc/rfc2747.txt", + key="RFC 2747", + abstract={This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, security", + doi="10.17487/RFC2747", + } + +@misc{rfc2748, + author="D. {Durham (Ed.)} and J. Boyle and R. Cohen and S. Herzog and R. Rajan and A. Sastry", + title="{The COPS (Common Open Policy Service) Protocol}", + howpublished="RFC 2748 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2748", + pages="1--38", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4261", +url="https://www.rfc-editor.org/rfc/rfc2748.txt", + key="RFC 2748", + abstract={This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS-TRACK]}, + keywords="COPS, qos, quality of service, signaling", + doi="10.17487/RFC2748", + } + +@misc{rfc2749, + author="S. {Herzog (Ed.)} and J. Boyle and R. Cohen and D. Durham and R. Rajan and A. Sastry", + title="{COPS usage for RSVP}", + howpublished="RFC 2749 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2749", + pages="1--17", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2749.txt", + key="RFC 2749", + abstract={This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS-TRACK]}, + keywords="common, open, policy, resource, reservation, protocol", + doi="10.17487/RFC2749", + } + +@misc{rfc2750, + author="S. Herzog", + title="{RSVP Extensions for Policy Control}", + howpublished="RFC 2750 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2750", + pages="1--13", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2750.txt", + key="RFC 2750", + abstract={This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, admission", + doi="10.17487/RFC2750", + } + +@misc{rfc2751, + author="S. Herzog", + title="{Signaled Preemption Priority Policy Element}", + howpublished="RFC 2751 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2751", + pages="1--12", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3181", +url="https://www.rfc-editor.org/rfc/rfc2751.txt", + key="RFC 2751", + abstract={This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS-TRACK]}, + keywords="RSVP, COPS, resource, reservation, protocol, common, open, service", + doi="10.17487/RFC2751", + } + +@misc{rfc2752, + author="S. Yadav and R. Yavatkar and R. Pabbati and P. Ford and T. Moore and S. Herzog", + title="{Identity Representation for RSVP}", + howpublished="RFC 2752 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2752", + pages="1--17", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3182", +url="https://www.rfc-editor.org/rfc/rfc2752.txt", + key="RFC 2752", + abstract={This document describes the representation of identity information in POLICY\_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, admission, authentication", + doi="10.17487/RFC2752", + } + +@misc{rfc2753, + author="R. Yavatkar and D. Pendarakis and R. Guerin", + title="{A Framework for Policy-based Admission Control}", + howpublished="RFC 2753 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2753", + pages="1--20", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2753.txt", + key="RFC 2753", + abstract={This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community.}, + doi="10.17487/RFC2753", + } + +@misc{rfc2754, + author="C. Alaettinoglu and C. Villamizar and R. Govindan", + title="{RPS IANA Issues}", + howpublished="RFC 2754 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2754", + pages="1--7", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6254", +url="https://www.rfc-editor.org/rfc/rfc2754.txt", + key="RFC 2754", + abstract={RPS Security requires certain RPSL objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA. This memo provides information for the Internet community.}, + keywords="internet, assigned, numbers, authority, routing, policy, specification, system, security", + doi="10.17487/RFC2754", + } + +@misc{rfc2755, + author="A. Chiu and M. Eisler and B. Callaghan", + title="{Security Negotiation for WebNFS}", + howpublished="RFC 2755 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2755", + pages="1--12", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2755.txt", + key="RFC 2755", + abstract={This document describes a protocol for a WebNFS client (RFC2054) to negotiate the desired security mechanism with a WebNFS server (RFC2055) before the WebNFS client falls back to the MOUNT v3 protocol (RFC1813). This document is provided so that people can write compatible implementations. This memo provides information for the Internet community.}, + keywords="RSVP, QOS, resource reservation, protocol, quality of service", + doi="10.17487/RFC2755", + } + +@misc{rfc2756, + author="P. Vixie and D. Wessels", + title="{Hyper Text Caching Protocol (HTCP/0.0)}", + howpublished="RFC 2756 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2756", + pages="1--15", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2756.txt", + key="RFC 2756", + abstract={This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. This memo defines an Experimental Protocol for the Internet community.}, + keywords="HTCP, hypertext, transfer protocol, caches, data", + doi="10.17487/RFC2756", + } + +@misc{rfc2757, + author="G. Montenegro and S. Dawkins and M. Kojo and V. Magret and N. Vaidya", + title="{Long Thin Networks}", + howpublished="RFC 2757 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2757", + pages="1--46", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2757.txt", + key="RFC 2757", + abstract={Our goal is to identify a TCP that works for all users, including users of long thin networks. This memo provides information for the Internet community.}, + keywords="wireless, WAN, wide area, networks, TCP, transmission, control, protocol", + doi="10.17487/RFC2757", + } + +@misc{rfc2758, + author="K. White", + title="{Definitions of Managed Objects for Service Level Agreements Performance Monitoring}", + howpublished="RFC 2758 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2758", + pages="1--71", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2758.txt", + key="RFC 2758", + abstract={This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MIB, management, information, base, SLAs", + doi="10.17487/RFC2758", + } + +@misc{rfc2759, + author="G. Zorn", + title="{Microsoft PPP CHAP Extensions, Version 2}", + howpublished="RFC 2759 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2759", + pages="1--20", + year=2000, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2759.txt", + key="RFC 2759", + abstract={This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1). This memo provides information for the Internet community.}, + keywords="point-to-point, protocol, challenge, handshake, authentication", + doi="10.17487/RFC2759", + } + +@misc{rfc2760, + author="M. {Allman (Ed.)} and S. Dawkins and D. Glover and J. Griner and D. Tran and T. Henderson and J. Heidemann and J. Touch and H. Kruse and S. Ostermann and K. Scott and J. Semke", + title="{Ongoing TCP Research Related to Satellites}", + howpublished="RFC 2760 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2760", + pages="1--46", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2760.txt", + key="RFC 2760", + abstract={This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. This memo provides information for the Internet community.}, + keywords="transmission, control, protocol, bandwidth, network, links", + doi="10.17487/RFC2760", + } + +@misc{rfc2761, + author="J. Dunn and C. Martin", + title="{Terminology for ATM Benchmarking}", + howpublished="RFC 2761 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2761", + pages="1--32", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2761.txt", + key="RFC 2761", + abstract={This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. This memo provides information for the Internet community.}, + keywords="asynchronous, transfer, mode, performance", + doi="10.17487/RFC2761", + } + +@misc{rfc2762, + author="J. Rosenberg and H. Schulzrinne", + title="{Sampling of the Group Membership in RTP}", + howpublished="RFC 2762 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2762", + pages="1--12", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2762.txt", + key="RFC 2762", + abstract={This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. This memo defines an Experimental Protocol for the Internet community.}, + keywords="real-time, transport, protocol, packets", + doi="10.17487/RFC2762", + } + +@misc{rfc2763, + author="N. Shen and H. Smit", + title="{Dynamic Hostname Exchange Mechanism for IS-IS}", + howpublished="RFC 2763 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2763", + pages="1--5", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5301", +url="https://www.rfc-editor.org/rfc/rfc2763.txt", + key="RFC 2763", + abstract={This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. This memo provides information for the Internet community.}, + keywords="intermediate, system, routers, TLV", + doi="10.17487/RFC2763", + } + +@misc{rfc2764, + author="B. Gleeson and A. Lin and J. Heinanen and G. Armitage and A. Malis", + title="{A Framework for IP Based Virtual Private Networks}", + howpublished="RFC 2764 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2764", + pages="1--62", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2764.txt", + key="RFC 2764", + abstract={This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.}, + keywords="VPN, internet protocol, backbone", + doi="10.17487/RFC2764", + } + +@misc{rfc2765, + author="E. Nordmark", + title="{Stateless IP/ICMP Translation Algorithm (SIIT)}", + howpublished="RFC 2765 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2765", + pages="1--26", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6145", +url="https://www.rfc-editor.org/rfc/rfc2765.txt", + key="RFC 2765", + abstract={This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS-TRACK]}, + keywords="SIIT, internet, protocol, control, message, IPv4, IPv6", + doi="10.17487/RFC2765", + } + +@misc{rfc2766, + author="G. Tsirtsis and P. Srisuresh", + title="{Network Address Translation - Protocol Translation (NAT-PT)}", + howpublished="RFC 2766 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2766", + pages="1--21", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4966, updated by RFC 3152", +url="https://www.rfc-editor.org/rfc/rfc2766.txt", + key="RFC 2766", + abstract={This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS-TRACK]}, + keywords="NAT-PT, IPv4, IPv6, internet", + doi="10.17487/RFC2766", + } + +@misc{rfc2767, + author="K. Tsuchiya and H. Higuchi and Y. Atarashi", + title="{Dual Stack Hosts using the ``Bump-In-the-Stack'' Technique (BIS)}", + howpublished="RFC 2767 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2767", + pages="1--13", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6535", +url="https://www.rfc-editor.org/rfc/rfc2767.txt", + key="RFC 2767", + abstract={This memo proposes a mechanism of dual stack hosts using the technique called ``Bump-in-the-Stack'' in the IP security area. This memo provides information for the Internet community.}, + keywords="IPv4, IPv6, internet, protocol, applications", + doi="10.17487/RFC2767", + } + +@misc{rfc2768, + author="B. Aiken and J. Strassner and B. Carpenter and I. Foster and C. Lynch and J. Mambretti and R. Moore and B. Teitelbaum", + title="{Network Policy and Services: A Report of a Workshop on Middleware}", + howpublished="RFC 2768 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2768", + pages="1--29", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2768.txt", + key="RFC 2768", + abstract={An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The need for a more organized framework for middleware R\&D was recognized, and a list of specific topics needing further work was identified. This memo provides information for the Internet community.}, + keywords="protocols, internet, applications", + doi="10.17487/RFC2768", + } + +@misc{rfc2769, + author="C. Villamizar and C. Alaettinoglu and R. Govindan and D. Meyer", + title="{Routing Policy System Replication}", + howpublished="RFC 2769 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2769", + pages="1--42", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2769.txt", + key="RFC 2769", + abstract={This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. [STANDARDS-TRACK]}, + keywords="RPSL, database, language", + doi="10.17487/RFC2769", + } + +@misc{rfc2770, + author="D. Meyer and P. Lothberg", + title="{GLOP Addressing in 233/8}", + howpublished="RFC 2770 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2770", + pages="1--5", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3180", +url="https://www.rfc-editor.org/rfc/rfc2770.txt", + key="RFC 2770", + abstract={This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This memo defines an Experimental Protocol for the Internet community.}, + keywords="multicast, allocation, global", + doi="10.17487/RFC2770", + } + +@misc{rfc2771, + author="R. Finlayson", + title="{An Abstract API for Multicast Address Allocation}", + howpublished="RFC 2771 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2771", + pages="1--11", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2771.txt", + key="RFC 2771", + abstract={This document describes the ``abstract service interface'' for the dynamic multicast address allocation service, as seen by applications. This memo provides information for the Internet community.}, + keywords="application, programming, interfaces, service", + doi="10.17487/RFC2771", + } + +@misc{rfc2772, + author="R. Rockell and R. Fink", + title="{6Bone Backbone Routing Guidelines}", + howpublished="RFC 2772 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2772", + pages="1--14", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3152", +url="https://www.rfc-editor.org/rfc/rfc2772.txt", + key="RFC 2772", + abstract={This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. This memo provides information for the Internet community.}, + keywords="IP, internet protocol, routing", + doi="10.17487/RFC2772", + } + +@misc{rfc2773, + author="R. Housley and P. Yee and W. Nace", + title="{Encryption using KEA and SKIPJACK}", + howpublished="RFC 2773 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2773", + pages="1--9", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2773.txt", + key="RFC 2773", + abstract={This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, ``File Transfer Protocol (FTP)'', (October}, + keywords="key exchange algorithm, symmetric", + doi="10.17487/RFC2773", + } + +@misc{rfc2774, + author="H. Nielsen and P. Leach and S. Lawrence", + title="{An HTTP Extension Framework}", + howpublished="RFC 2774 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2774", + pages="1--20", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2774.txt", + key="RFC 2774", + abstract={This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. This memo defines an Experimental Protocol for the Internet community.}, + keywords="hyper-text, transfer, protocol", + doi="10.17487/RFC2774", + } + +@misc{rfc2775, + author="B. Carpenter", + title="{Internet Transparency}", + howpublished="RFC 2775 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2775", + pages="1--18", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2775.txt", + key="RFC 2775", + abstract={This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.}, + keywords="end-to-end, network layer, connectivity", + doi="10.17487/RFC2775", + } + +@misc{rfc2776, + author="M. Handley and D. Thaler and R. Kermode", + title="{Multicast-Scope Zone Announcement Protocol (MZAP)}", + howpublished="RFC 2776 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2776", + pages="1--27", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2776.txt", + key="RFC 2776", + abstract={This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. [STANDARDS-TRACK]}, + keywords="MZAP, packets, addresses, service, location", + doi="10.17487/RFC2776", + } + +@misc{rfc2777, + author="D. {Eastlake 3rd}", + title="{Publicly Verifiable Nomcom Random Selection}", + howpublished="RFC 2777 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2777", + pages="1--16", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3797", +url="https://www.rfc-editor.org/rfc/rfc2777.txt", + key="RFC 2777", + abstract={This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. This memo provides information for the Internet community.}, + keywords="Internet, Engineering, Task Force, IETF", + doi="10.17487/RFC2777", + } + +@misc{rfc2778, + author="M. Day and J. Rosenberg and H. Sugano", + title="{A Model for Presence and Instant Messaging}", + howpublished="RFC 2778 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2778", + pages="1--17", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2778.txt", + key="RFC 2778", + abstract={This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. This memo provides information for the Internet community.}, + keywords="service users, MIME, multipurpose, Internet, mail, extensions", + doi="10.17487/RFC2778", + } + +@misc{rfc2779, + author="M. Day and S. Aggarwal and G. Mohr and J. Vincent", + title="{Instant Messaging / Presence Protocol Requirements}", + howpublished="RFC 2779 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2779", + pages="1--26", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2779.txt", + key="RFC 2779", + abstract={This document defines a minimal set of requirements that IMPP must meet. This memo provides information for the Internet community.}, + keywords="MIME, multipurpose, Internet, mail extensions, service, users", + doi="10.17487/RFC2779", + } + +@misc{rfc2780, + author="S. Bradner and V. Paxson", + title="{IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers}", + howpublished="RFC 2780 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2780", + pages="1--10", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4443, 5237, 5771, 6335, 7045", +url="https://www.rfc-editor.org/rfc/rfc2780.txt", + key="RFC 2780", + abstract={This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, assigned, numbers, authority, IP", + doi="10.17487/RFC2780", + } + +@misc{rfc2781, + author="P. Hoffman and F. Yergeau", + title="{UTF-16, an encoding of ISO 10646}", + howpublished="RFC 2781 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2781", + pages="1--14", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2781.txt", + key="RFC 2781", + abstract={This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community.}, + keywords="unicode, character, data, code, point", + doi="10.17487/RFC2781", + } + +@misc{rfc2782, + author="A. Gulbrandsen and P. Vixie and L. Esibov", + title="{A DNS RR for specifying the location of services (DNS SRV)}", + howpublished="RFC 2782 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2782", + pages="1--12", + year=2000, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6335", +url="https://www.rfc-editor.org/rfc/rfc2782.txt", + key="RFC 2782", + abstract={This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]}, + keywords="DNS-SRV, domain, name, system, resource, record", + doi="10.17487/RFC2782", + } + +@misc{rfc2783, + author="J. Mogul and D. Mills and J. Brittenson and J. Stone and U. Windl", + title="{Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0}", + howpublished="RFC 2783 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2783", + pages="1--31", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2783.txt", + key="RFC 2783", + abstract={RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. This memo provides information for the Internet community.}, + keywords="NTP, time, clock, synchronization", + doi="10.17487/RFC2783", + } + +@misc{rfc2784, + author="D. Farinacci and T. Li and S. Hanks and D. Meyer and P. Traina", + title="{Generic Routing Encapsulation (GRE)}", + howpublished="RFC 2784 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2784", + pages="1--9", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 2890", +url="https://www.rfc-editor.org/rfc/rfc2784.txt", + key="RFC 2784", + abstract={This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]}, + keywords="GRE, packet, size, payload", + doi="10.17487/RFC2784", + } + +@misc{rfc2785, + author="R. Zuccherato", + title="{Methods for Avoiding the ``Small-Subgroup'' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME}", + howpublished="RFC 2785 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2785", + pages="1--11", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2785.txt", + key="RFC 2785", + abstract={This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community.}, + keywords="security, multipurpose, internet, mail extensions", + doi="10.17487/RFC2785", + } + +@misc{rfc2786, + author="M. St. Johns", + title="{Diffie-Helman USM Key Management Information Base and Textual Convention}", + howpublished="RFC 2786 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2786", + pages="1--20", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2786.txt", + key="RFC 2786", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community.}, + keywords="mib, security, user-based, model, Hellman", + doi="10.17487/RFC2786", + } + +@misc{rfc2787, + author="B. Jewell and D. Chuang", + title="{Definitions of Managed Objects for the Virtual Router Redundancy Protocol}", + howpublished="RFC 2787 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2787", + pages="1--31", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6527", +url="https://www.rfc-editor.org/rfc/rfc2787.txt", + key="RFC 2787", + abstract={This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP). [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2787", + } + +@misc{rfc2788, + author="N. Freed and S. Kille", + title="{Network Services Monitoring MIB}", + howpublished="RFC 2788 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2788", + pages="1--22", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2788.txt", + key="RFC 2788", + abstract={This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2788", + } + +@misc{rfc2789, + author="N. Freed and S. Kille", + title="{Mail Monitoring MIB}", + howpublished="RFC 2789 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2789", + pages="1--33", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2789.txt", + key="RFC 2789", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2789", + } + +@misc{rfc2790, + author="S. Waldbusser and P. Grillo", + title="{Host Resources MIB}", + howpublished="RFC 2790 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2790", + pages="1--50", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2790.txt", + key="RFC 2790", + abstract={This memo obsoletes RFC 1514, the ``Host Resources MIB''. This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2790", + } + +@misc{rfc2791, + author="J. Yu", + title="{Scalable Routing Design Principles}", + howpublished="RFC 2791 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2791", + pages="1--26", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2791.txt", + key="RFC 2791", + abstract={This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. This memo provides information for the Internet community.}, + keywords="network, packets", + doi="10.17487/RFC2791", + } + +@misc{rfc2792, + author="M. Blaze and J. Ioannidis and A. Keromytis", + title="{DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System}", + howpublished="RFC 2792 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2792", + pages="1--7", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2792.txt", + key="RFC 2792", + abstract={This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community.}, + keywords="cryptology, digial, signatures", + doi="10.17487/RFC2792", + } + +@misc{rfc2793, + author="G. Hellstrom", + title="{RTP Payload for Text Conversation}", + howpublished="RFC 2793 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2793", + pages="1--10", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4103", +url="https://www.rfc-editor.org/rfc/rfc2793.txt", + key="RFC 2793", + abstract={This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS-TRACK]}, + keywords="real-time, applications, video, audio, packets", + doi="10.17487/RFC2793", + } + +@misc{rfc2794, + author="P. Calhoun and C. Perkins", + title="{Mobile IP Network Access Identifier Extension for IPv4}", + howpublished="RFC 2794 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2794", + pages="1--9", + year=2000, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2794.txt", + key="RFC 2794", + abstract={Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. [STANDARDS-TRACK]}, + keywords="internet, protocol, NAI", + doi="10.17487/RFC2794", + } + +@misc{rfc2795, + author="S. Christey", + title="{The Infinite Monkey Protocol Suite (IMPS)}", + howpublished="RFC 2795 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2795", + pages="1--20", + year=2000, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2795.txt", + key="RFC 2795", + abstract={This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. This memo provides information for the Internet community.}, + keywords="control, packet, client", + doi="10.17487/RFC2795", + } + +@misc{rfc2796, + author="T. Bates and R. Chandra and E. Chen", + title="{BGP Route Reflection - An Alternative to Full Mesh IBGP}", + howpublished="RFC 2796 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2796", + pages="1--11", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4456", +url="https://www.rfc-editor.org/rfc/rfc2796.txt", + key="RFC 2796", + abstract={This document describes the use and design of a method known as ``Route Reflection'' to alleviate the the need for ``full mesh'' IBGP. [STANDARDS-TRACK]}, + keywords="border, gateway, protocol", + doi="10.17487/RFC2796", + } + +@misc{rfc2797, + author="M. Myers and X. Liu and J. Schaad and J. Weinstein", + title="{Certificate Management Messages over CMS}", + howpublished="RFC 2797 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2797", + pages="1--47", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5272", +url="https://www.rfc-editor.org/rfc/rfc2797.txt", + key="RFC 2797", + abstract={This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS-TRACK]}, + keywords="certificate, management, protocol, cryptology, syntax", + doi="10.17487/RFC2797", + } + +@misc{rfc2798, + author="M. Smith", + title="{Definition of the inetOrgPerson LDAP Object Class}", + howpublished="RFC 2798 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2798", + pages="1--20", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3698, 4519, 4524", +url="https://www.rfc-editor.org/rfc/rfc2798.txt", + key="RFC 2798", + abstract={We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol, directory services", + doi="10.17487/RFC2798", + } + +@misc{rfc2799, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 2700-2799}", + howpublished="RFC 2799 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2799", + pages="1--23", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2799.txt", + key="RFC 2799", + doi="10.17487/RFC2799", + } + +@misc{rfc2800, + author="J. Reynolds and R. Braden and S. Ginoza", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2800 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2800", + pages="1--38", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 2900", +url="https://www.rfc-editor.org/rfc/rfc2800.txt", + key="RFC 2800", + abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS-TRACK]}, + doi="10.17487/RFC2800", + } + +@misc{rfc2801, + author="D. Burdett", + title="{Internet Open Trading Protocol - IOTP Version 1.0}", + howpublished="RFC 2801 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2801", + pages="1--290", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2801.txt", + key="RFC 2801", + abstract={This document discusses the Internet Open Trading Protocol (IOTP) and its provision of an interoperable framework for Internet commerce. This memo provides information for the Internet community.}, + keywords="commerce, payment, system, merchant", + doi="10.17487/RFC2801", + } + +@misc{rfc2802, + author="K. Davidson and Y. Kawatsura", + title="{Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)}", + howpublished="RFC 2802 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2802", + pages="1--29", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2802.txt", + key="RFC 2802", + abstract={This document describes the syntax and procedures for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). This memo provides information for the Internet community.}, + keywords="commerce, payment system, xml, extensible, markup, language, security", + doi="10.17487/RFC2802", + } + +@misc{rfc2803, + author="H. Maruyama and K. Tamura and N. Uramoto", + title="{Digest Values for DOM (DOMHASH)}", + howpublished="RFC 2803 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2803", + pages="1--11", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2803.txt", + key="RFC 2803", + abstract={This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This memo provides information for the Internet community.}, + keywords="xml, extensible, markup, language, secruity", + doi="10.17487/RFC2803", + } + +@misc{rfc2804, + author="IAB and IESG", + title="{IETF Policy on Wiretapping}", + howpublished="RFC 2804 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2804", + pages="1--10", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2804.txt", + key="RFC 2804", + abstract={This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is ``no'', and what that answer means. This memo provides information for the Internet community.}, + keywords="internet, engineering, task force", + doi="10.17487/RFC2804", + } + +@misc{rfc2805, + author="N. Greene and M. Ramalho and B. Rosen", + title="{Media Gateway Control Protocol Architecture and Requirements}", + howpublished="RFC 2805 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2805", + pages="1--45", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2805.txt", + key="RFC 2805", + abstract={This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway. This memo provides information for the Internet community.}, + keywords="MG, mapping, transcoding, network", + doi="10.17487/RFC2805", + } + +@misc{rfc2806, + author="A. Vaha-Sipila", + title="{URLs for Telephone Calls}", + howpublished="RFC 2806 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2806", + pages="1--21", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3966", +url="https://www.rfc-editor.org/rfc/rfc2806.txt", + key="RFC 2806", + abstract={This document specifies URL (Uniform Resource Locator) schemes ``tel'', ``fax'' and ``modem'' for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS-TRACK]}, + keywords="uniform, resource, locator, schemes", + doi="10.17487/RFC2806", + } + +@misc{rfc2807, + author="J. Reagle", + title="{XML Signature Requirements}", + howpublished="RFC 2807 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2807", + pages="1--9", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2807.txt", + key="RFC 2807", + abstract={This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. This memo provides information for the Internet community.}, + keywords="digital, extensible, markup, language", + doi="10.17487/RFC2807", + } + +@misc{rfc2808, + author="M. Nystrom", + title="{The SecurID(r) SASL Mechanism}", + howpublished="RFC 2808 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2808", + pages="1--11", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2808.txt", + key="RFC 2808", + abstract={This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments. This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo provides information for the Internet community.}, + keywords="simple, authentication, security, layer", + doi="10.17487/RFC2808", + } + +@misc{rfc2809, + author="B. Aboba and G. Zorn", + title="{Implementation of L2TP Compulsory Tunneling via RADIUS}", + howpublished="RFC 2809 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2809", + pages="1--23", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2809.txt", + key="RFC 2809", + abstract={This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP (Layer Two Tunneling Protocol) protocol. This memo provides information for the Internet community.}, + keywords="remote, authentication, dial-in, user, service, layer, two", + doi="10.17487/RFC2809", + } + +@misc{rfc2810, + author="C. Kalt", + title="{Internet Relay Chat: Architecture}", + howpublished="RFC 2810 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2810", + pages="1--10", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2810.txt", + key="RFC 2810", + abstract={This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. This memo provides information for the Internet community.}, + keywords="IRC, text based, conferencing", + doi="10.17487/RFC2810", + } + +@misc{rfc2811, + author="C. Kalt", + title="{Internet Relay Chat: Channel Management}", + howpublished="RFC 2811 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2811", + pages="1--19", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2811.txt", + key="RFC 2811", + abstract={This document specifies how channels, their characteristics and properties are managed by IRC servers. This memo provides information for the Internet community.}, + keywords="IRC, text based, conferencing", + doi="10.17487/RFC2811", + } + +@misc{rfc2812, + author="C. Kalt", + title="{Internet Relay Chat: Client Protocol}", + howpublished="RFC 2812 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2812", + pages="1--63", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2812.txt", + key="RFC 2812", + abstract={This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture. This memo provides information for the Internet community.}, + keywords="IRC, text based, conferencing", + doi="10.17487/RFC2812", + } + +@misc{rfc2813, + author="C. Kalt", + title="{Internet Relay Chat: Server Protocol}", + howpublished="RFC 2813 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2813", + pages="1--26", + year=2000, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2813.txt", + key="RFC 2813", + abstract={This document defines the protocol used by servers to talk to each other. This memo provides information for the Internet community.}, + keywords="IRC, text based, conferencing", + doi="10.17487/RFC2813", + } + +@misc{rfc2814, + author="R. Yavatkar and D. Hoffman and Y. Bernet and F. Baker and M. Speer", + title="{SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks}", + howpublished="RFC 2814 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2814", + pages="1--60", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2814.txt", + key="RFC 2814", + abstract={This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS-TRACK]}, + keywords="LAN, local area, resource, reservation", + doi="10.17487/RFC2814", + } + +@misc{rfc2815, + author="M. Seaman and A. Smith and E. Crawley and J. Wroclawski", + title="{Integrated Service Mappings on IEEE 802 Networks}", + howpublished="RFC 2815 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2815", + pages="1--17", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2815.txt", + key="RFC 2815", + abstract={This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). [STANDARDS-TRACK]}, + keywords="LAN, local area, resource, reservation", + doi="10.17487/RFC2815", + } + +@misc{rfc2816, + author="A. Ghanwani and J. Pace and V. Srinivasan and A. Smith and M. Seaman", + title="{A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies}", + howpublished="RFC 2816 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2816", + pages="1--47", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2816.txt", + key="RFC 2816", + abstract={This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. This memo provides information for the Internet community.}, + keywords="LAN, local area, network, parameter, switches", + doi="10.17487/RFC2816", + } + +@misc{rfc2817, + author="R. Khare and S. Lawrence", + title="{Upgrading to TLS Within HTTP/1.1}", + howpublished="RFC 2817 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2817", + pages="1--13", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7230, 7231", +url="https://www.rfc-editor.org/rfc/rfc2817.txt", + key="RFC 2817", + abstract={This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]}, + keywords="hypertext, transfer, protocol, transport, layer, security", + doi="10.17487/RFC2817", + } + +@misc{rfc2818, + author="E. Rescorla", + title="{HTTP Over TLS}", + howpublished="RFC 2818 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2818", + pages="1--7", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5785, 7230", +url="https://www.rfc-editor.org/rfc/rfc2818.txt", + key="RFC 2818", + abstract={This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.}, + keywords="hypertext, transfer, protocol, transport, layer, security", + doi="10.17487/RFC2818", + } + +@misc{rfc2819, + author="S. Waldbusser", + title="{Remote Network Monitoring Management Information Base}", + howpublished="RFC 2819 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2819", + pages="1--98", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2819.txt", + key="RFC 2819", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]}, + keywords="RMON-MIB, MIB, RMON", + doi="10.17487/RFC2819", + } + +@misc{rfc2820, + author="E. Stokes and D. Byrne and B. Blakley and P. Behera", + title="{Access Control Requirements for LDAP}", + howpublished="RFC 2820 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2820", + pages="1--9", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2820.txt", + key="RFC 2820", + abstract={This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol", + doi="10.17487/RFC2820", + } + +@misc{rfc2821, + author="J. {Klensin (Ed.)}", + title="{Simple Mail Transfer Protocol}", + howpublished="RFC 2821 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2821", + pages="1--79", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5321, updated by RFC 5336", +url="https://www.rfc-editor.org/rfc/rfc2821.txt", + key="RFC 2821", + abstract={This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS-TRACK]}, + keywords="SMTP", + doi="10.17487/RFC2821", + } + +@misc{rfc2822, + author="P. {Resnick (Ed.)}", + title="{Internet Message Format}", + howpublished="RFC 2822 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2822", + pages="1--51", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5322, updated by RFCs 5335, 5336", +url="https://www.rfc-editor.org/rfc/rfc2822.txt", + key="RFC 2822", + abstract={This document specifies a syntax for text messages that are sent between computer users, within the framework of ``electronic mail'' messages. [STANDARDS-TRACK]}, + keywords="MAIL", + doi="10.17487/RFC2822", + } + +@misc{rfc2823, + author="J. Carlson and P. Langner and E. Hernandez-Valencia and J. Manchester", + title="{PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing}", + howpublished="RFC 2823 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2823", + pages="1--28", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2823.txt", + key="RFC 2823", + abstract={This document extends methods found in the Point-to-Point Protocol (PPP) and RFCs 1662 and 2615 to include a new encapsulation for PPP called Simple Data Link (SDL). SDL provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. This memo defines an Experimental Protocol for the Internet community.}, + keywords="PPP-SDL, point-to-point, protocol, synchronous, optical, network, digital, hierarchy, data link, simple", + doi="10.17487/RFC2823", + } + +@misc{rfc2824, + author="J. Lennox and H. Schulzrinne", + title="{Call Processing Language Framework and Requirements}", + howpublished="RFC 2824 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2824", + pages="1--25", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2824.txt", + key="RFC 2824", + abstract={This document describes an architectural framework we call a processing language, as a simple and standardized way for implementing and deploying Internet telephony. A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. It also outlines requirements for such a language. This memo provides information for the Internet community.}, + keywords="CPL-F, telephony, signalling, network, devices", + doi="10.17487/RFC2824", + } + +@misc{rfc2825, + author="IAB and L. {Daigle (Ed.)}", + title="{A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols}", + howpublished="RFC 2825 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2825", + pages="1--7", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2825.txt", + key="RFC 2825", + abstract={This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. This memo provides information for the Internet community.}, + keywords="character sets, e-commerce, interoperability", + doi="10.17487/RFC2825", + } + +@misc{rfc2826, + author="Internet Architecture Board", + title="{IAB Technical Comment on the Unique DNS Root}", + howpublished="RFC 2826 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2826", + pages="1--6", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2826.txt", + key="RFC 2826", + abstract={This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community.}, + keywords="Internet Architecture Board, domain name, system", + doi="10.17487/RFC2826", + } + +@misc{rfc2827, + author="P. Ferguson and D. Senie", + title="{Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing}", + howpublished="RFC 2827 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2827", + pages="1--10", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3704", +url="https://www.rfc-editor.org/rfc/rfc2827.txt", + key="RFC 2827", + abstract={This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="ISP, Internet, Service, Provider, Internet, Protocol, DOS", + doi="10.17487/RFC2827", + } + +@misc{rfc2828, + author="R. Shirey", + title="{Internet Security Glossary}", + howpublished="RFC 2828 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2828", + pages="1--212", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4949", +url="https://www.rfc-editor.org/rfc/rfc2828.txt", + key="RFC 2828", + abstract={This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology. This memo provides information for the Internet community.}, + keywords="information, system, ISD, internet, standard documents", + doi="10.17487/RFC2828", + } + +@misc{rfc2829, + author="M. Wahl and H. Alvestrand and J. Hodges and R. Morgan", + title="{Authentication Methods for LDAP}", + howpublished="RFC 2829 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2829", + pages="1--16", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4513, 4510, updated by RFC 3377", +url="https://www.rfc-editor.org/rfc/rfc2829.txt", + key="RFC 2829", + abstract={This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol, security", + doi="10.17487/RFC2829", + } + +@misc{rfc2830, + author="J. Hodges and R. Morgan and M. Wahl", + title="{Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security}", + howpublished="RFC 2830 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2830", + pages="1--12", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4511, 4513, 4510, updated by RFC 3377", +url="https://www.rfc-editor.org/rfc/rfc2830.txt", + key="RFC 2830", + abstract={This document defines the ``Start Transport Layer Security (TLS) Operation'' for LDAP. [STANDARDS-TRACK]}, + keywords="LDAP, TLS", + doi="10.17487/RFC2830", + } + +@misc{rfc2831, + author="P. Leach and C. Newman", + title="{Using Digest Authentication as a SASL Mechanism}", + howpublished="RFC 2831 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2831", + pages="1--27", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6331", +url="https://www.rfc-editor.org/rfc/rfc2831.txt", + key="RFC 2831", + abstract={This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS-TRACK]}, + keywords="http, hypertext, transfer, protocol, security, simple, layer", + doi="10.17487/RFC2831", + } + +@misc{rfc2832, + author="S. Hollenbeck and M. Srivastava", + title="{NSI Registry Registrar Protocol (RRP) Version 1.1.0}", + howpublished="RFC 2832 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2832", + pages="1--39", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3632", +url="https://www.rfc-editor.org/rfc/rfc2832.txt", + key="RFC 2832", + abstract={This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This memo provides information for the Internet community.}, + keywords="RRP, shared, registration, system, gLTD, ccTLD, top level domain", + doi="10.17487/RFC2832", + } + +@misc{rfc2833, + author="H. Schulzrinne and S. Petrack", + title="{RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals}", + howpublished="RFC 2833 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2833", + pages="1--30", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4733, 4734", +url="https://www.rfc-editor.org/rfc/rfc2833.txt", + key="RFC 2833", + abstract={This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS-TRACK]}, + keywords="real-time, application, protocol, DTMF, dual-tone, multifrequency", + doi="10.17487/RFC2833", + } + +@misc{rfc2834, + author="J.-M. Pittet", + title="{ARP and IP Broadcast over HIPPI-800}", + howpublished="RFC 2834 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2834", + pages="1--34", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc2834.txt", + key="RFC 2834", + abstract={This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP (hardware addresses). This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC 2067 ``IP over HIPPI'') obsoletes RFC 1374. [STANDARDS-TRACK]}, + keywords="address resolution, protocol, internet, high-performance, internface, parallel", + doi="10.17487/RFC2834", + } + +@misc{rfc2835, + author="J.-M. Pittet", + title="{IP and ARP over HIPPI-6400 (GSN)}", + howpublished="RFC 2835 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2835", + pages="1--33", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc2835.txt", + key="RFC 2835", + abstract={This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore, it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. [STANDARDS-TRACK]}, + keywords="GSN, address resolution, protocol, internet, high-performance, internface, parallel", + doi="10.17487/RFC2835", + } + +@misc{rfc2836, + author="S. Brim and B. Carpenter and F. Le Faucheur", + title="{Per Hop Behavior Identification Codes}", + howpublished="RFC 2836 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2836", + pages="1--7", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3140", +url="https://www.rfc-editor.org/rfc/rfc2836.txt", + key="RFC 2836", + abstract={This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS-TRACK]}, + keywords="PHB, differentiated, services, codepoint, DSCP", + doi="10.17487/RFC2836", + } + +@misc{rfc2837, + author="K. Teow", + title="{Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard}", + howpublished="RFC 2837 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2837", + pages="1--48", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4044", +url="https://www.rfc-editor.org/rfc/rfc2837.txt", + key="RFC 2837", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. [STANDARDS-TRACK]}, + keywords="MIB, management, information, base", + doi="10.17487/RFC2837", + } + +@misc{rfc2838, + author="D. Zigmond and M. Vickers", + title="{Uniform Resource Identifiers for Television Broadcasts}", + howpublished="RFC 2838 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2838", + pages="1--6", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2838.txt", + key="RFC 2838", + abstract={This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community.}, + keywords="URI, TV, WWW, world wide web", + doi="10.17487/RFC2838", + } + +@misc{rfc2839, + author="F. da Cruz and J. Altman", + title="{Internet Kermit Service}", + howpublished="RFC 2839 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2839", + pages="1--20", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2839.txt", + key="RFC 2839", + abstract={This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community.}, + keywords="file, transfer, management, service", + doi="10.17487/RFC2839", + } + +@misc{rfc2840, + author="J. Altman and F. da Cruz", + title="{TELNET KERMIT OPTION}", + howpublished="RFC 2840 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2840", + pages="1--12", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2840.txt", + key="RFC 2840", + abstract={This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community.}, + keywords="file transfer, management, service", + doi="10.17487/RFC2840", + } + +@misc{rfc2841, + author="P. Metzger and W. Simpson", + title="{IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)}", + howpublished="RFC 2841 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2841", + pages="1--9", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2841.txt", + key="RFC 2841", + abstract={This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header. This memo defines a Historic Document for the Internet community.}, + keywords="IP-MAC, encryption, secure, hash, algorithm", + doi="10.17487/RFC2841", + } + +@misc{rfc2842, + author="R. Chandra and J. Scudder", + title="{Capabilities Advertisement with BGP-4}", + howpublished="RFC 2842 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2842", + pages="1--5", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3392", +url="https://www.rfc-editor.org/rfc/rfc2842.txt", + key="RFC 2842", + abstract={This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. [STANDARDS-TRACK]}, + keywords="border, gateway, protocol", + doi="10.17487/RFC2842", + } + +@misc{rfc2843, + author="P. Droz and T. Przygienda", + title="{Proxy-PAR}", + howpublished="RFC 2843 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2843", + pages="1--13", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2843.txt", + key="RFC 2843", + abstract={The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS-TRACK]}, + keywords="PNNI augmented Routing, ATM, asynchronous, transfer mode", + doi="10.17487/RFC2843", + } + +@misc{rfc2844, + author="T. Przygienda and P. Droz and R. Haas", + title="{OSPF over ATM and Proxy-PAR}", + howpublished="RFC 2844 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2844", + pages="1--14", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2844.txt", + key="RFC 2844", + abstract={This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC (Permanent Virtual Connections) and SVC (Switched Virtual Circuit) meshes with the presence of Proxy-PAR (PNNI Augmented Routing). This memo defines an Experimental Protocol for the Internet community.}, + keywords="PNNI augmented Routing, asynchronous transfer mode, open shortest-path first", + doi="10.17487/RFC2844", + } + +@misc{rfc2845, + author="P. Vixie and O. Gudmundsson and D. {Eastlake 3rd} and B. Wellington", + title="{Secret Key Transaction Authentication for DNS (TSIG)}", + howpublished="RFC 2845 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2845", + pages="1--15", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3645, 4635, 6895", +url="https://www.rfc-editor.org/rfc/rfc2845.txt", + key="RFC 2845", + abstract={This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK]}, + keywords="TSIG, domain, name, system, transaction, signature", + doi="10.17487/RFC2845", + } + +@misc{rfc2846, + author="C. Allocchio", + title="{GSTN Address Element Extensions in E-mail Services}", + howpublished="RFC 2846 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2846", + pages="1--35", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3191, 3192", +url="https://www.rfc-editor.org/rfc/rfc2846.txt", + key="RFC 2846", + abstract={This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS-TRACK]}, + keywords="global, switched, telephone, network", + doi="10.17487/RFC2846", + } + +@misc{rfc2847, + author="M. Eisler", + title="{LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM}", + howpublished="RFC 2847 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2847", + pages="1--22", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2847.txt", + key="RFC 2847", + abstract={This memorandum describes a method whereby one can use GSS-API (Generic Security Service Application Program Interface) to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. [STANDARDS-TRACK]}, + keywords="LIPKEY, client, server, simple pubilc, key mechanism, authentication", + doi="10.17487/RFC2847", + } + +@misc{rfc2848, + author="S. Petrack and L. Conroy", + title="{The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services}", + howpublished="RFC 2848 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2848", + pages="1--73", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2848.txt", + key="RFC 2848", + abstract={This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. [STANDARDS-TRACK]}, + keywords="session, initiation, protocol, internet, description", + doi="10.17487/RFC2848", + } + +@misc{rfc2849, + author="G. Good", + title="{The LDAP Data Interchange Format (LDIF) - Technical Specification}", + howpublished="RFC 2849 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2849", + pages="1--14", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2849.txt", + key="RFC 2849", + abstract={This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS-TRACK]}, + keywords="LDIF, lightweight, directory, access, protocol file", + doi="10.17487/RFC2849", + } + +@misc{rfc2850, + author="Internet Architecture Board and B. {Carpenter (Ed.)}", + title="{Charter of the Internet Architecture Board (IAB)}", + howpublished="RFC 2850 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2850", + pages="1--8", + year=2000, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2850.txt", + key="RFC 2850", + abstract={This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="ISOC, Internet Society, IETF, IRTF", + doi="10.17487/RFC2850", + } + +@misc{rfc2851, + author="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder", + title="{Textual Conventions for Internet Network Addresses}", + howpublished="RFC 2851 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2851", + pages="1--16", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3291", +url="https://www.rfc-editor.org/rfc/rfc2851.txt", + key="RFC 2851", + abstract={This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]}, + keywords="layer, management, information, base, inet, address mib", + doi="10.17487/RFC2851", + } + +@misc{rfc2852, + author="D. Newman", + title="{Deliver By SMTP Service Extension}", + howpublished="RFC 2852 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2852", + pages="1--13", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2852.txt", + key="RFC 2852", + abstract={This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS-TRACK]}, + keywords="simple, mail transfer, protocol, client server", + doi="10.17487/RFC2852", + } + +@misc{rfc2853, + author="J. Kabat and M. Upadhyay", + title="{Generic Security Service API Version 2 : Java Bindings}", + howpublished="RFC 2853 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2853", + pages="1--96", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5653", +url="https://www.rfc-editor.org/rfc/rfc2853.txt", + key="RFC 2853", + abstract={This document specifies the Java bindings for GSS-API (Generic Security Service Application Program Interface) which is described at a language independent conceptual level in RFC 2743. [STANDARDS-TRACK]}, + keywords="GSI, application program, interface", + doi="10.17487/RFC2853", + } + +@misc{rfc2854, + author="D. Connolly and L. Masinter", + title="{The 'text/html' Media Type}", + howpublished="RFC 2854 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2854", + pages="1--8", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2854.txt", + key="RFC 2854", + abstract={This document summarizes the history of HTML development, and defines the ``text/html'' MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.}, + keywords="HTML-INT, HTML, WWW, World, Wide, Web", + doi="10.17487/RFC2854", + } + +@misc{rfc2855, + author="K. Fujisawa", + title="{DHCP for IEEE 1394}", + howpublished="RFC 2855 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2855", + pages="1--5", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2855.txt", + key="RFC 2855", + abstract={This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages. IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol, high performance, serial bus", + doi="10.17487/RFC2855", + } + +@misc{rfc2856, + author="A. Bierman and K. McCloghrie and R. Presuhn", + title="{Textual Conventions for Additional High Capacity Data Types}", + howpublished="RFC 2856 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2856", + pages="1--10", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2856.txt", + key="RFC 2856", + abstract={This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS-TRACK]}, + keywords="SNMP, simple, network, management, protocol", + doi="10.17487/RFC2856", + } + +@misc{rfc2857, + author="A. Keromytis and N. Provos", + title="{The Use of HMAC-RIPEMD-160-96 within ESP and AH}", + howpublished="RFC 2857 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2857", + pages="1--7", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2857.txt", + key="RFC 2857", + abstract={This memo describes the use of the HMAC algorithm in conjunction with the RIPEMD-160 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload (ESP) and the revised IPSEC Authentication Header (AH). [STANDARDS-TRACK]}, + keywords="ipsec, encapsulating, security, payload, authentication", + doi="10.17487/RFC2857", + } + +@misc{rfc2858, + author="T. Bates and Y. Rekhter and R. Chandra and D. Katz", + title="{Multiprotocol Extensions for BGP-4}", + howpublished="RFC 2858 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2858", + pages="1--11", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4760", +url="https://www.rfc-editor.org/rfc/rfc2858.txt", + key="RFC 2858", + abstract={This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK]}, + keywords="MEXT-BGP4, Border, gateway, protocol, router, network, layer", + doi="10.17487/RFC2858", + } + +@misc{rfc2859, + author="W. Fang and N. Seddigh and B. Nandy", + title="{A Time Sliding Window Three Colour Marker (TSWTCM)}", + howpublished="RFC 2859 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2859", + pages="1--9", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2859.txt", + key="RFC 2859", + abstract={This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner. This memo defines an Experimental Protocol for the Internet community.}, + keywords="TSWTCM, packets, traffic, stream, routers", + doi="10.17487/RFC2859", + } + +@misc{rfc2860, + author="B. Carpenter and F. Baker and M. Roberts", + title="{Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority}", + howpublished="RFC 2860 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2860", + pages="1--7", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2860.txt", + key="RFC 2860", + abstract={This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.}, + keywords="mou, iana, ietf, icann, engineering, task force, corporation names", + doi="10.17487/RFC2860", + } + +@misc{rfc2861, + author="M. Handley and J. Padhye and S. Floyd", + title="{TCP Congestion Window Validation}", + howpublished="RFC 2861 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2861", + pages="1--11", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7661", +url="https://www.rfc-editor.org/rfc/rfc2861.txt", + key="RFC 2861", + abstract={This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. This memo defines an Experimental Protocol for the Internet community.}, + keywords="transmission, control, protocol", + doi="10.17487/RFC2861", + } + +@misc{rfc2862, + author="M. Civanlar and G. Cash", + title="{RTP Payload Format for Real-Time Pointers}", + howpublished="RFC 2862 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2862", + pages="1--7", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2862.txt", + key="RFC 2862", + abstract={This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS-TRACK]}, + keywords="view graphs, resolution, audio, video, signals", + doi="10.17487/RFC2862", + } + +@misc{rfc2863, + author="K. McCloghrie and F. Kastenholz", + title="{The Interfaces Group MIB}", + howpublished="RFC 2863 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2863", + pages="1--69", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2863.txt", + key="RFC 2863", + abstract={This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK]}, + keywords="INTERGRMIB, Management, Information, Base, Network", + doi="10.17487/RFC2863", + } + +@misc{rfc2864, + author="K. McCloghrie and G. Hanson", + title="{The Inverted Stack Table Extension to the Interfaces Group MIB}", + howpublished="RFC 2864 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2864", + pages="1--11", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2864.txt", + key="RFC 2864", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2864", + } + +@misc{rfc2865, + author="C. Rigney and S. Willens and A. Rubens and W. Simpson", + title="{Remote Authentication Dial In User Service (RADIUS)}", + howpublished="RFC 2865 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2865", + pages="1--76", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2868, 3575, 5080, 6929, 8044", +url="https://www.rfc-editor.org/rfc/rfc2865.txt", + key="RFC 2865", + abstract={This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]}, + keywords="RADIUS, encryption, NAS, Network, Access, Server", + doi="10.17487/RFC2865", + } + +@misc{rfc2866, + author="C. Rigney", + title="{RADIUS Accounting}", + howpublished="RFC 2866 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2866", + pages="1--28", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 2867, 5080, 5997", +url="https://www.rfc-editor.org/rfc/rfc2866.txt", + key="RFC 2866", + abstract={This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community.}, + keywords="RADIUS-ACC, remote, authentication, dial, in, user, service, encryption", + doi="10.17487/RFC2866", + } + +@misc{rfc2867, + author="G. Zorn and B. Aboba and D. Mitton", + title="{RADIUS Accounting Modifications for Tunnel Protocol Support}", + howpublished="RFC 2867 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2867", + pages="1--11", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2867.txt", + key="RFC 2867", + abstract={This document defines new RADIUS (Remote Authentication Dial In User Service) accounting Attributes and new values for the existing Acct- Status-Type Attribute designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.}, + keywords="RADIUS], encryption, NAS, Network, Access, Server", + doi="10.17487/RFC2867", + } + +@misc{rfc2868, + author="G. Zorn and D. Leifer and A. Rubens and J. Shriver and M. Holdrege and I. Goyret", + title="{RADIUS Attributes for Tunnel Protocol Support}", + howpublished="RFC 2868 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2868", + pages="1--20", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3575", +url="https://www.rfc-editor.org/rfc/rfc2868.txt", + key="RFC 2868", + abstract={This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.}, + keywords="RADIUS, encryption, NAS, Network, Access, Server", + doi="10.17487/RFC2868", + } + +@misc{rfc2869, + author="C. Rigney and W. Willats and P. Calhoun", + title="{RADIUS Extensions}", + howpublished="RFC 2869 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2869", + pages="1--47", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3579, 5080", +url="https://www.rfc-editor.org/rfc/rfc2869.txt", + key="RFC 2869", + abstract={This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community.}, + keywords="RADIUS, encryption, NAS, Network, Access, Server", + doi="10.17487/RFC2869", + } + +@misc{rfc2870, + author="R. Bush and D. Karrenberg and M. Kosters and R. Plzak", + title="{Root Name Server Operational Requirements}", + howpublished="RFC 2870 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2870", + pages="1--10", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7720", +url="https://www.rfc-editor.org/rfc/rfc2870.txt", + key="RFC 2870", + abstract={The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="infrastructure, domain names, security", + doi="10.17487/RFC2870", + } + +@misc{rfc2871, + author="J. Rosenberg and H. Schulzrinne", + title="{A Framework for Telephony Routing over IP}", + howpublished="RFC 2871 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2871", + pages="1--25", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2871.txt", + key="RFC 2871", + abstract={This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. This memo provides information for the Internet community.}, + keywords="internet, protocol, TRIP, gateway", + doi="10.17487/RFC2871", + } + +@misc{rfc2872, + author="Y. Bernet and R. Pabbati", + title="{Application and Sub Application Identity Policy Element for Use with RSVP}", + howpublished="RFC 2872 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2872", + pages="1--6", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2872.txt", + key="RFC 2872", + abstract={RSVP signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol", + doi="10.17487/RFC2872", + } + +@misc{rfc2873, + author="X. Xiao and A. Hannan and V. Paxson and E. Crabbe", + title="{TCP Processing of the IPv4 Precedence Field}", + howpublished="RFC 2873 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2873", + pages="1--8", + year=2000, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2873.txt", + key="RFC 2873", + abstract={This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]}, + keywords="transmission, control, protocol, internet", + doi="10.17487/RFC2873", + } + +@misc{rfc2874, + author="M. Crawford and C. Huitema", + title="{DNS Extensions to Support IPv6 Address Aggregation and Renumbering}", + howpublished="RFC 2874 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2874", + pages="1--20", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3152, 3226, 3363, 3364", +url="https://www.rfc-editor.org/rfc/rfc2874.txt", + key="RFC 2874", + abstract={This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]}, + keywords="internet, protocol, domain, name, system", + doi="10.17487/RFC2874", + } + +@misc{rfc2875, + author="H. Prafullchandra and J. Schaad", + title="{Diffie-Hellman Proof-of-Possession Algorithms}", + howpublished="RFC 2875 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2875", + pages="1--23", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6955", +url="https://www.rfc-editor.org/rfc/rfc2875.txt", + key="RFC 2875", + abstract={This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS-TRACK]}, + keywords="certificate, security, encryption", + doi="10.17487/RFC2875", + } + +@misc{rfc2876, + author="J. Pawling", + title="{Use of the KEA and SKIPJACK Algorithms in CMS}", + howpublished="RFC 2876 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2876", + pages="1--13", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2876.txt", + key="RFC 2876", + abstract={This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. This memo provides information for the Internet community.}, + keywords="encryption, cryptographic, message, syntax", + doi="10.17487/RFC2876", + } + +@misc{rfc2877, + author="T. {Murphy Jr.} and P. Rieth and J. Stevens", + title="{5250 Telnet Enhancements}", + howpublished="RFC 2877 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2877", + pages="1--36", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4777", +url="https://www.rfc-editor.org/rfc/rfc2877.txt", + key="RFC 2877", + abstract={This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. This memo provides information for the Internet community.}, + keywords="client, server, printer", + doi="10.17487/RFC2877", + } + +@misc{rfc2878, + author="M. Higashiyama and F. Baker", + title="{PPP Bridging Control Protocol (BCP)}", + howpublished="RFC 2878 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2878", + pages="1--38", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3518", +url="https://www.rfc-editor.org/rfc/rfc2878.txt", + key="RFC 2878", + abstract={This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]}, + keywords="PPP-BCP, point-to-point, datagrams, network", + doi="10.17487/RFC2878", + } + +@misc{rfc2879, + author="G. Klyne and L. McIntyre", + title="{Content Feature Schema for Internet Fax (V2)}", + howpublished="RFC 2879 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2879", + pages="1--58", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2879.txt", + key="RFC 2879", + abstract={This document defines a content media feature schema for Internet fax. [STANDARDS-TRACK]}, + keywords="media, features, mechanism", + doi="10.17487/RFC2879", + } + +@misc{rfc2880, + author="L. McIntyre and G. Klyne", + title="{Internet Fax T.30 Feature Mapping}", + howpublished="RFC 2880 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2880", + pages="1--37", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2880.txt", + key="RFC 2880", + abstract={This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in ``Content feature schema for Internet fax''. This memo provides information for the Internet community.}, + keywords="schema, media, tags", + doi="10.17487/RFC2880", + } + +@misc{rfc2881, + author="D. Mitton and M. Beadles", + title="{Network Access Server Requirements Next Generation (NASREQNG) NAS Model}", + howpublished="RFC 2881 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2881", + pages="1--20", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2881.txt", + key="RFC 2881", + abstract={This document describes the terminology and gives a model of typical Network Access Server (NAS). This memo provides information for the Internet community.}, + keywords="RADIUS, remote, authentication, dial-up, user service", + doi="10.17487/RFC2881", + } + +@misc{rfc2882, + author="D. Mitton", + title="{Network Access Servers Requirements: Extended RADIUS Practices}", + howpublished="RFC 2882 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2882", + pages="1--16", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2882.txt", + key="RFC 2882", + abstract={This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS (Remote Authentication Dial In User Service) RFCs 2138, 2139. This memo provides information for the Internet community.}, + keywords="NAS, remote, authentication, dial-in, user service", + doi="10.17487/RFC2882", + } + +@misc{rfc2883, + author="S. Floyd and J. Mahdavi and M. Mathis and M. Podolsky", + title="{An Extension to the Selective Acknowledgement (SACK) Option for TCP}", + howpublished="RFC 2883 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2883", + pages="1--17", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2883.txt", + key="RFC 2883", + abstract={This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]}, + keywords="SACK, transmission, control, protocol, packets, sender, receiver", + doi="10.17487/RFC2883", + } + +@misc{rfc2884, + author="J. Hadi Salim and U. Ahmed", + title="{Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks}", + howpublished="RFC 2884 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2884", + pages="1--18", + year=2000, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2884.txt", + key="RFC 2884", + abstract={This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community.}, + keywords="internet, protocol, end-to-end, TCP, transmission, control", + doi="10.17487/RFC2884", + } + +@misc{rfc2885, + author="F. Cuervo and N. Greene and C. Huitema and A. Rayhan and B. Rosen and J. Segers", + title="{Megaco Protocol version 0.8}", + howpublished="RFC 2885 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2885", + pages="1--170", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3015", +url="https://www.rfc-editor.org/rfc/rfc2885.txt", + key="RFC 2885", + abstract={This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. [STANDARDS-TRACK]}, + keywords="H.248, media, gateway, control", + doi="10.17487/RFC2885", + } + +@misc{rfc2886, + author="T. Taylor", + title="{Megaco Errata}", + howpublished="RFC 2886 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2886", + pages="1--21", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3015", +url="https://www.rfc-editor.org/rfc/rfc2886.txt", + key="RFC 2886", + abstract={This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS-TRACK]}, + keywords="H.248, media, gateway, control", + doi="10.17487/RFC2886", + } + +@misc{rfc2887, + author="M. Handley and S. Floyd and B. Whetten and R. Kermode and L. Vicisano and M. Luby", + title="{The Reliable Multicast Design Space for Bulk Data Transfer}", + howpublished="RFC 2887 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2887", + pages="1--22", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2887.txt", + key="RFC 2887", + abstract={This document provides an overview of the design space and the ways in which application constraints affect possible solutions. This memo provides information for the Internet community.}, + keywords="application, RM, congestion, control, data", + doi="10.17487/RFC2887", + } + +@misc{rfc2888, + author="P. Srisuresh", + title="{Secure Remote Access with L2TP}", + howpublished="RFC 2888 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2888", + pages="1--19", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2888.txt", + key="RFC 2888", + abstract={The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This memo provides information for the Internet community.}, + keywords="layer two, tunneling, protocol", + doi="10.17487/RFC2888", + } + +@misc{rfc2889, + author="R. Mandeville and J. Perser", + title="{Benchmarking Methodology for LAN Switching Devices}", + howpublished="RFC 2889 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2889", + pages="1--35", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2889.txt", + key="RFC 2889", + abstract={This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community.}, + keywords="local, area, network, MAC, medium, access, control", + doi="10.17487/RFC2889", + } + +@misc{rfc2890, + author="G. Dommety", + title="{Key and Sequence Number Extensions to GRE}", + howpublished="RFC 2890 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2890", + pages="1--7", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2890.txt", + key="RFC 2890", + abstract={This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]}, + keywords="generic, routing, encapsulation", + doi="10.17487/RFC2890", + } + +@misc{rfc2891, + author="T. Howes and M. Wahl and A. Anantha", + title="{LDAP Control Extension for Server Side Sorting of Search Results}", + howpublished="RFC 2891 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2891", + pages="1--8", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2891.txt", + key="RFC 2891", + abstract={This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol", + doi="10.17487/RFC2891", + } + +@misc{rfc2892, + author="D. Tsiang and G. Suwala", + title="{The Cisco SRP MAC Layer Protocol}", + howpublished="RFC 2892 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2892", + pages="1--52", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2892.txt", + key="RFC 2892", + abstract={This document specifies the MAC layer protocol, ``Spatial Reuse Protocol'' (SRP) for use with ring based media. This is a second version of the protocol (V2). This memo provides information for the Internet community.}, + keywords="spatial, reuse", + doi="10.17487/RFC2892", + } + +@misc{rfc2893, + author="R. Gilligan and E. Nordmark", + title="{Transition Mechanisms for IPv6 Hosts and Routers}", + howpublished="RFC 2893 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2893", + pages="1--29", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4213", +url="https://www.rfc-editor.org/rfc/rfc2893.txt", + key="RFC 2893", + abstract={This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]}, + keywords="TRANS-IPV6, IPv4", + doi="10.17487/RFC2893", + } + +@misc{rfc2894, + author="M. Crawford", + title="{Router Renumbering for IPv6}", + howpublished="RFC 2894 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2894", + pages="1--32", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2894.txt", + key="RFC 2894", + abstract={This document defines a mechanism called Router Renumbering (``RR'') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. [STANDARDS-TRACK]}, + keywords="internet, protocol, operations, scalability, applicability", + doi="10.17487/RFC2894", + } + +@misc{rfc2895, + author="A. Bierman and C. Bucci and R. Iddon", + title="{Remote Network Monitoring MIB Protocol Identifier Reference}", + howpublished="RFC 2895 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="2895", + pages="1--42", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3395", +url="https://www.rfc-editor.org/rfc/rfc2895.txt", + key="RFC 2895", + abstract={This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding ``INDEX`` values for the protocolDirTable, found in the RMON-2 MIB. [STANDARDS-TRACK]}, + keywords="RMON-MIB, management, information, base", + doi="10.17487/RFC2895", + } + +@misc{rfc2896, + author="A. Bierman and C. Bucci and R. Iddon", + title="{Remote Network Monitoring MIB Protocol Identifier Macros}", + howpublished="RFC 2896 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2896", + pages="1--84", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2896.txt", + key="RFC 2896", + abstract={This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB and the RMON Protocol Identifier Reference. This memo provides information for the Internet community.}, + keywords="RMON, management, information, base", + doi="10.17487/RFC2896", + } + +@misc{rfc2897, + author="D. Cromwell", + title="{Proposal for an MGCP Advanced Audio Package}", + howpublished="RFC 2897 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2897", + pages="1--34", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2897.txt", + key="RFC 2897", + abstract={This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This memo provides information for the Internet community.}, + keywords="media, gateway, control, protocol, IVR, interactive, voice, response", + doi="10.17487/RFC2897", + } + +@misc{rfc2898, + author="B. Kaliski", + title="{PKCS \#5: Password-Based Cryptography Specification Version 2.0}", + howpublished="RFC 2898 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2898", + pages="1--34", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8018", +url="https://www.rfc-editor.org/rfc/rfc2898.txt", + key="RFC 2898", + abstract={This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.}, + keywords="public-key, authentication, encryption", + doi="10.17487/RFC2898", + } + +@misc{rfc2899, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 2800-2899}", + howpublished="RFC 2899 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2899", + pages="1--22", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2899.txt", + key="RFC 2899", + doi="10.17487/RFC2899", + } + +@misc{rfc2900, + author="J. Reynolds and R. Braden and S. Ginoza", + title="{Internet Official Protocol Standards}", + howpublished="RFC 2900 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2900", + pages="1--42", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3000", +url="https://www.rfc-editor.org/rfc/rfc2900.txt", + key="RFC 2900", + abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. This memo is an Internet Standard.}, + doi="10.17487/RFC2900", + } + +@misc{rfc2901, + author="Z. Wenzel and J. Klensin and R. Bush and S. Huter", + title="{Guide to Administrative Procedures of the Internet Infrastructure}", + howpublished="RFC 2901 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2901", + pages="1--31", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2901.txt", + key="RFC 2901", + abstract={This document describes the administrative procedures for networks seeking to connect to the global Internet. This memo provides information for the Internet community.}, + keywords="address space, routing, database, domain name, registration", + doi="10.17487/RFC2901", + } + +@misc{rfc2902, + author="S. Deering and S. Hares and C. Perkins and R. Perlman", + title="{Overview of the 1998 IAB Routing Workshop}", + howpublished="RFC 2902 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2902", + pages="1--16", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2902.txt", + key="RFC 2902", + abstract={This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. This memo provides information for the Internet community.}, + keywords="internet, architecture, board", + doi="10.17487/RFC2902", + } + +@misc{rfc2903, + author="C. de Laat and G. Gross and L. Gommans and J. Vollbrecht and D. Spence", + title="{Generic AAA Architecture}", + howpublished="RFC 2903 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2903", + pages="1--26", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2903.txt", + key="RFC 2903", + abstract={This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. This memo defines an Experimental Protocol for the Internet community.}, + keywords="authentication, authorization, accounting", + doi="10.17487/RFC2903", + } + +@misc{rfc2904, + author="J. Vollbrecht and P. Calhoun and S. Farrell and L. Gommans and G. Gross and B. de Bruijn and C. de Laat and M. Holdrege and D. Spence", + title="{AAA Authorization Framework}", + howpublished="RFC 2904 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2904", + pages="1--35", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2904.txt", + key="RFC 2904", + abstract={This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community.}, + keywords="authentication, authorization, accounting", + doi="10.17487/RFC2904", + } + +@misc{rfc2905, + author="J. Vollbrecht and P. Calhoun and S. Farrell and L. Gommans and G. Gross and B. de Bruijn and C. de Laat and M. Holdrege and D. Spence", + title="{AAA Authorization Application Examples}", + howpublished="RFC 2905 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2905", + pages="1--53", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2905.txt", + key="RFC 2905", + abstract={This memo describes several examples of applications requiring authorization. This memo provides information for the Internet community.}, + keywords="authentication, authorization, accounting", + doi="10.17487/RFC2905", + } + +@misc{rfc2906, + author="S. Farrell and J. Vollbrecht and P. Calhoun and L. Gommans and G. Gross and B. de Bruijn and C. de Laat and M. Holdrege and D. Spence", + title="{AAA Authorization Requirements}", + howpublished="RFC 2906 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2906", + pages="1--23", + year=2000, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2906.txt", + key="RFC 2906", + abstract={This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. This memo provides information for the Internet community.}, + keywords="authentication, authorization, accounting", + doi="10.17487/RFC2906", + } + +@misc{rfc2907, + author="R. Kermode", + title="{MADCAP Multicast Scope Nesting State Option}", + howpublished="RFC 2907 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2907", + pages="1--13", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2907.txt", + key="RFC 2907", + abstract={This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS-TRACK]}, + keywords="address, dynamic, allocation, client, protocol", + doi="10.17487/RFC2907", + } + +@misc{rfc2908, + author="D. Thaler and M. Handley and D. Estrin", + title="{The Internet Multicast Address Allocation Architecture}", + howpublished="RFC 2908 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2908", + pages="1--13", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6308", +url="https://www.rfc-editor.org/rfc/rfc2908.txt", + key="RFC 2908", + abstract={This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community.}, + keywords="MALLOC, host server, intra-domain, inter-domain", + doi="10.17487/RFC2908", + } + +@misc{rfc2909, + author="P. Radoslavov and D. Estrin and R. Govindan and M. Handley and S. Kumar and D. Thaler", + title="{The Multicast Address-Set Claim (MASC) Protocol}", + howpublished="RFC 2909 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2909", + pages="1--56", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2909.txt", + key="RFC 2909", + abstract={This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. This memo defines an Experimental Protocol for the Internet community.}, + keywords="MASC, inter-domain, router", + doi="10.17487/RFC2909", + } + +@misc{rfc2910, + author="R. {Herriot (Ed.)} and S. Butler and P. Moore and R. Turner and J. Wenn", + title="{Internet Printing Protocol/1.1: Encoding and Transport}", + howpublished="RFC 2910 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2910", + pages="1--46", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8010, updated by RFCs 3380, 3381, 3382, 3510, 3995, 7472", +url="https://www.rfc-editor.org/rfc/rfc2910.txt", + key="RFC 2910", + abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]}, + keywords="IPP-E-T, IPP, application, media-type, media, type", + doi="10.17487/RFC2910", + } + +@misc{rfc2911, + author="T. {Hastings (Ed.)} and R. Herriot and R. deBry and S. Isaacson and P. Powell", + title="{Internet Printing Protocol/1.1: Model and Semantics}", + howpublished="RFC 2911 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2911", + pages="1--224", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8011, updated by RFCs 3380, 3382, 3996, 3995, 7472", +url="https://www.rfc-editor.org/rfc/rfc2911.txt", + key="RFC 2911", + abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]}, + keywords="IPP-M-S, IPP, application, media-type, job", + doi="10.17487/RFC2911", + } + +@misc{rfc2912, + author="G. Klyne", + title="{Indicating Media Features for MIME Content}", + howpublished="RFC 2912 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2912", + pages="1--11", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2912.txt", + key="RFC 2912", + abstract={This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS-TRACK]}, + keywords="multipurpose, mail extensions, tag, format", + doi="10.17487/RFC2912", + } + +@misc{rfc2913, + author="G. Klyne", + title="{MIME Content Types in Media Feature Expressions}", + howpublished="RFC 2913 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2913", + pages="1--9", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2913.txt", + key="RFC 2913", + abstract={This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS-TRACK]}, + keywords="multipurpose, mail extensions, tag, format", + doi="10.17487/RFC2913", + } + +@misc{rfc2914, + author="S. Floyd", + title="{Congestion Control Principles}", + howpublished="RFC 2914 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2914", + pages="1--17", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7141", +url="https://www.rfc-editor.org/rfc/rfc2914.txt", + key="RFC 2914", + abstract={The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="end-to-end", + doi="10.17487/RFC2914", + } + +@misc{rfc2915, + author="M. Mealling and R. Daniel", + title="{The Naming Authority Pointer (NAPTR) DNS Resource Record}", + howpublished="RFC 2915 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2915", + pages="1--18", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 3401, 3402, 3403, 3404", +url="https://www.rfc-editor.org/rfc/rfc2915.txt", + key="RFC 2915", + abstract={This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). [STANDARDS-TRACK]}, + keywords="NAPTR, domain name system, RR", + doi="10.17487/RFC2915", + } + +@misc{rfc2916, + author="P. Faltstrom", + title="{E.164 number and DNS}", + howpublished="RFC 2916 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2916", + pages="1--10", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3761", +url="https://www.rfc-editor.org/rfc/rfc2916.txt", + key="RFC 2916", + abstract={This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]}, + keywords="domain name system", + doi="10.17487/RFC2916", + } + +@misc{rfc2917, + author="K. Muthukrishnan and A. Malis", + title="{A Core MPLS IP VPN Architecture}", + howpublished="RFC 2917 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2917", + pages="1--16", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2917.txt", + key="RFC 2917", + abstract={This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This memo provides information for the Internet community.}, + keywords="internet protocol, virtual private networks, multiprotocol label switching", + doi="10.17487/RFC2917", + } + +@misc{rfc2918, + author="E. Chen", + title="{Route Refresh Capability for BGP-4}", + howpublished="RFC 2918 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2918", + pages="1--4", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7313", +url="https://www.rfc-editor.org/rfc/rfc2918.txt", + key="RFC 2918", + abstract={This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]}, + keywords="border, gateway, protocol", + doi="10.17487/RFC2918", + } + +@misc{rfc2919, + author="R. Chandhok and G. Wenger", + title="{List-Id: A Structured Field and Namespace for the Identification of Mailing Lists}", + howpublished="RFC 2919 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2919", + pages="1--9", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2919.txt", + key="RFC 2919", + abstract={Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK]}, + keywords="server, clients, user agents", + doi="10.17487/RFC2919", + } + +@misc{rfc2920, + author="N. Freed", + title="{SMTP Service Extension for Command Pipelining}", + howpublished="RFC 2920 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="2920", + pages="1--9", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2920.txt", + key="RFC 2920", + abstract={This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK]}, + keywords="SMTP-Pipe, simple, mail, transfer, protocol, TCP, transmission, control, protocol", + doi="10.17487/RFC2920", + } + +@misc{rfc2921, + author="B. Fink", + title="{6BONE pTLA and pNLA Formats (pTLA)}", + howpublished="RFC 2921 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2921", + pages="1--7", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2921.txt", + key="RFC 2921", + abstract={This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, ``IPv6 Testing Address Allocation'', to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). This memo provides information for the Internet community.}, + keywords="IPv6, internet, protocol, pseudo, top-level, next-level, aggregation, identifiers", + doi="10.17487/RFC2921", + } + +@misc{rfc2922, + author="A. Bierman and K. Jones", + title="{Physical Topology MIB}", + howpublished="RFC 2922 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2922", + pages="1--32", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2922.txt", + key="RFC 2922", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. This memo provides information for the Internet community.}, + keywords="management, information, base", + doi="10.17487/RFC2922", + } + +@misc{rfc2923, + author="K. Lahey", + title="{TCP Problems with Path MTU Discovery}", + howpublished="RFC 2923 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2923", + pages="1--15", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2923.txt", + key="RFC 2923", + abstract={This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This memo provides information for the Internet community.}, + keywords="transmission, control, protocol, maximum, unit", + doi="10.17487/RFC2923", + } + +@misc{rfc2924, + author="N. Brownlee and A. Blount", + title="{Accounting Attributes and Record Formats}", + howpublished="RFC 2924 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2924", + pages="1--36", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2924.txt", + key="RFC 2924", + abstract={This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. This memo provides information for the Internet community.}, + keywords="data, transport, integrated", + doi="10.17487/RFC2924", + } + +@misc{rfc2925, + author="K. White", + title="{Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations}", + howpublished="RFC 2925 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2925", + pages="1--77", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4560", +url="https://www.rfc-editor.org/rfc/rfc2925.txt", + key="RFC 2925", + abstract={This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS-TRACK]}, + keywords="mib, management, information, base", + doi="10.17487/RFC2925", + } + +@misc{rfc2926, + author="J. Kempf and R. Moats and P. St. Pierre", + title="{Conversion of LDAP Schemas to and from SLP Templates}", + howpublished="RFC 2926 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2926", + pages="1--27", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2926.txt", + key="RFC 2926", + abstract={This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. This memo provides information for the Internet community.}, + keywords="service location, protocol, lightweight, directory, access", + doi="10.17487/RFC2926", + } + +@misc{rfc2927, + author="M. Wahl", + title="{MIME Directory Profile for LDAP Schema}", + howpublished="RFC 2927 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2927", + pages="1--10", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2927.txt", + key="RFC 2927", + abstract={This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2927", + } + +@misc{rfc2928, + author="R. Hinden and S. Deering and R. Fink and T. Hain", + title="{Initial IPv6 Sub-TLA ID Assignments}", + howpublished="RFC 2928 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2928", + pages="1--7", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2928.txt", + key="RFC 2928", + abstract={This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. This memo provides information for the Internet community.}, + keywords="internet protocol, sub-top-level, aggregation, identifiers, address, registries", + doi="10.17487/RFC2928", + } + +@misc{rfc2929, + author="D. {Eastlake 3rd} and E. Brunner-Williams and B. Manning", + title="{Domain Name System (DNS) IANA Considerations}", + howpublished="RFC 2929 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2929", + pages="1--12", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5395", +url="https://www.rfc-editor.org/rfc/rfc2929.txt", + key="RFC 2929", + abstract={This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet assigned numbers authority, resource records, RRs", + doi="10.17487/RFC2929", + } + +@misc{rfc2930, + author="D. {Eastlake 3rd}", + title="{Secret Key Establishment for DNS (TKEY RR)}", + howpublished="RFC 2930 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2930", + pages="1--16", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6895", +url="https://www.rfc-editor.org/rfc/rfc2930.txt", + key="RFC 2930", + abstract={This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS-TRACK]}, + keywords="TKEY-RR, domain name system, resource record, transaction key", + doi="10.17487/RFC2930", + } + +@misc{rfc2931, + author="D. {Eastlake 3rd}", + title="{DNS Request and Transaction Signatures ( SIG(0)s )}", + howpublished="RFC 2931 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2931", + pages="1--10", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2931.txt", + key="RFC 2931", + abstract={This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]}, + keywords="domain name system, data, security", + doi="10.17487/RFC2931", + } + +@misc{rfc2932, + author="K. McCloghrie and D. Farinacci and D. Thaler", + title="{IPv4 Multicast Routing MIB}", + howpublished="RFC 2932 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2932", + pages="1--27", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5132", +url="https://www.rfc-editor.org/rfc/rfc2932.txt", + key="RFC 2932", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. [STANDARDS-TRACK]}, + keywords="internet, protocol, management, information, base", + doi="10.17487/RFC2932", + } + +@misc{rfc2933, + author="K. McCloghrie and D. Farinacci and D. Thaler", + title="{Internet Group Management Protocol MIB}", + howpublished="RFC 2933 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2933", + pages="1--19", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5519", +url="https://www.rfc-editor.org/rfc/rfc2933.txt", + key="RFC 2933", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). [STANDARDS-TRACK]}, + keywords="igmp, management, information, base", + doi="10.17487/RFC2933", + } + +@misc{rfc2934, + author="K. McCloghrie and D. Farinacci and D. Thaler and B. Fenner", + title="{Protocol Independent Multicast MIB for IPv4}", + howpublished="RFC 2934 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2934", + pages="1--27", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2934.txt", + key="RFC 2934", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. This memo defines an Experimental Protocol for the Internet community.}, + keywords="internet, protocol, management, information, base", + doi="10.17487/RFC2934", + } + +@misc{rfc2935, + author="D. {Eastlake 3rd} and C. Smith", + title="{Internet Open Trading Protocol (IOTP) HTTP Supplement}", + howpublished="RFC 2935 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2935", + pages="1--8", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2935.txt", + key="RFC 2935", + abstract={The goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. [STANDARDS-TRACK]}, + keywords="IOTP-HTTP, hypertext, XML, extensible, markup, language, transfer", + doi="10.17487/RFC2935", + } + +@misc{rfc2936, + author="D. {Eastlake 3rd} and C. Smith and D. Soroka", + title="{HTTP MIME Type Handler Detection}", + howpublished="RFC 2936 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2936", + pages="1--13", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2936.txt", + key="RFC 2936", + abstract={Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. This memo provides information for the Internet community.}, + keywords="multipurpose, internet, mail, extensions, hypertext, transfer, protocol", + doi="10.17487/RFC2936", + } + +@misc{rfc2937, + author="C. Smith", + title="{The Name Service Search Option for DHCP}", + howpublished="RFC 2937 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2937", + pages="1--5", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2937.txt", + key="RFC 2937", + abstract={This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol", + doi="10.17487/RFC2937", + } + +@misc{rfc2938, + author="G. Klyne and L. Masinter", + title="{Identifying Composite Media Features}", + howpublished="RFC 2938 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2938", + pages="1--18", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2938.txt", + key="RFC 2938", + abstract={This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS-TRACK]}, + keywords="tags, expression, hash", + doi="10.17487/RFC2938", + } + +@misc{rfc2939, + author="R. Droms", + title="{Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types}", + howpublished="RFC 2939 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2939", + pages="1--7", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2939.txt", + key="RFC 2939", + abstract={This document describes the procedure for defining new DHCP options and message types. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="dynamic, host, configuration, protocol, internet, assigned, numbers, authority", + doi="10.17487/RFC2939", + } + +@misc{rfc2940, + author="A. Smith and D. Partain and J. Seligson", + title="{Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients}", + howpublished="RFC 2940 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2940", + pages="1--27", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2940.txt", + key="RFC 2940", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. [STANDARDS-TRACK]}, + keywords="cops, mib, management, information, base", + doi="10.17487/RFC2940", + } + +@misc{rfc2941, + author="T. {Ts'o (Ed.)} and J. Altman", + title="{Telnet Authentication Option}", + howpublished="RFC 2941 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2941", + pages="1--15", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2941.txt", + key="RFC 2941", + abstract={This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS-TRACK]}, + keywords="TOPT-AUTH, encryption, Security", + doi="10.17487/RFC2941", + } + +@misc{rfc2942, + author="T. Ts'o", + title="{Telnet Authentication: Kerberos Version 5}", + howpublished="RFC 2942 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2942", + pages="1--7", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2942.txt", + key="RFC 2942", + abstract={This document describes how Kerberos Version 5 is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS-TRACK]}, + keywords="encryption", + doi="10.17487/RFC2942", + } + +@misc{rfc2943, + author="R. Housley and T. Horting and P. Yee", + title="{TELNET Authentication Using DSA}", + howpublished="RFC 2943 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2943", + pages="1--12", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2943.txt", + key="RFC 2943", + abstract={This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option. [STANDARDS-TRACK]}, + keywords="digital, signature, algorithm", + doi="10.17487/RFC2943", + } + +@misc{rfc2944, + author="T. Wu", + title="{Telnet Authentication: SRP}", + howpublished="RFC 2944 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2944", + pages="1--7", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2944.txt", + key="RFC 2944", + abstract={This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS-TRACK]}, + keywords="secure, remote, password, protocol", + doi="10.17487/RFC2944", + } + +@misc{rfc2945, + author="T. Wu", + title="{The SRP Authentication and Key Exchange System}", + howpublished="RFC 2945 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2945", + pages="1--8", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2945.txt", + key="RFC 2945", + abstract={This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]}, + keywords="secure, remote, password, protocol", + doi="10.17487/RFC2945", + } + +@misc{rfc2946, + author="T. Ts'o", + title="{Telnet Data Encryption Option}", + howpublished="RFC 2946 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2946", + pages="1--8", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2946.txt", + key="RFC 2946", + abstract={This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]}, + keywords="stream, authentication", + doi="10.17487/RFC2946", + } + +@misc{rfc2947, + author="J. Altman", + title="{Telnet Encryption: DES3 64 bit Cipher Feedback}", + howpublished="RFC 2947 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2947", + pages="1--6", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2947.txt", + key="RFC 2947", + abstract={This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS-TRACK]}, + keywords="data, encryption, standard", + doi="10.17487/RFC2947", + } + +@misc{rfc2948, + author="J. Altman", + title="{Telnet Encryption: DES3 64 bit Output Feedback}", + howpublished="RFC 2948 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2948", + pages="1--6", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2948.txt", + key="RFC 2948", + abstract={This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS-TRACK]}, + keywords="data, encryption, standard", + doi="10.17487/RFC2948", + } + +@misc{rfc2949, + author="J. Altman", + title="{Telnet Encryption: CAST-128 64 bit Output Feedback}", + howpublished="RFC 2949 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2949", + pages="1--5", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2949.txt", + key="RFC 2949", + abstract={This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]}, + keywords="algorithm, option", + doi="10.17487/RFC2949", + } + +@misc{rfc2950, + author="J. Altman", + title="{Telnet Encryption: CAST-128 64 bit Cipher Feedback}", + howpublished="RFC 2950 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2950", + pages="1--5", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2950.txt", + key="RFC 2950", + abstract={This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]}, + keywords="algorithm, option", + doi="10.17487/RFC2950", + } + +@misc{rfc2951, + author="R. Housley and T. Horting and P. Yee", + title="{TELNET Authentication Using KEA and SKIPJACK}", + howpublished="RFC 2951 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2951", + pages="1--11", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2951.txt", + key="RFC 2951", + abstract={This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. This memo provides information for the Internet community.}, + keywords="key exchange, algorithm, encryption", + doi="10.17487/RFC2951", + } + +@misc{rfc2952, + author="T. Ts'o", + title="{Telnet Encryption: DES 64 bit Cipher Feedback}", + howpublished="RFC 2952 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2952", + pages="1--5", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2952.txt", + key="RFC 2952", + abstract={This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. This memo provides information for the Internet community.}, + keywords="data, encryption, standard", + doi="10.17487/RFC2952", + } + +@misc{rfc2953, + author="T. Ts'o", + title="{Telnet Encryption: DES 64 bit Output Feedback}", + howpublished="RFC 2953 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2953", + pages="1--5", + year=2000, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2953.txt", + key="RFC 2953", + abstract={This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. This memo provides information for the Internet community.}, + keywords="data, encryption, standard", + doi="10.17487/RFC2953", + } + +@misc{rfc2954, + author="K. Rehbehn and D. Fowler", + title="{Definitions of Managed Objects for Frame Relay Service}", + howpublished="RFC 2954 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2954", + pages="1--76", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2954.txt", + key="RFC 2954", + abstract={This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. [STANDARDS-TRACK]}, + keywords="FR-MIB, mib, management, information, base", + doi="10.17487/RFC2954", + } + +@misc{rfc2955, + author="K. Rehbehn and O. Nicklass and G. Mouradian", + title="{Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function}", + howpublished="RFC 2955 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2955", + pages="1--39", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2955.txt", + key="RFC 2955", + abstract={This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. [STANDARDS-TRACK]}, + keywords="asynchronous, transfer, mode, permanent, virtual, connections, MIB, management, information, base", + doi="10.17487/RFC2955", + } + +@misc{rfc2956, + author="M. Kaat", + title="{Overview of 1999 IAB Network Layer Workshop}", + howpublished="RFC 2956 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2956", + pages="1--16", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2956.txt", + key="RFC 2956", + abstract={This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. This memo provides information for the Internet community.}, + keywords="intenret, architecture, board", + doi="10.17487/RFC2956", + } + +@misc{rfc2957, + author="L. Daigle and P. Faltstrom", + title="{The application/whoispp-query Content-Type}", + howpublished="RFC 2957 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2957", + pages="1--6", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2957.txt", + key="RFC 2957", + abstract={The intention of this document, in conjunction with RFC 2958, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.}, + keywords="mime, multipurpose, internet, mail, extensions, media-types", + doi="10.17487/RFC2957", + } + +@misc{rfc2958, + author="L. Daigle and P. Faltstrom", + title="{The application/whoispp-response Content-type}", + howpublished="RFC 2958 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2958", + pages="1--6", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2958.txt", + key="RFC 2958", + abstract={The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.}, + keywords="mime, multipurpose, internet, mail, extensions, media-types", + doi="10.17487/RFC2958", + } + +@misc{rfc2959, + author="M. Baugher and B. Strahm and I. Suconick", + title="{Real-Time Transport Protocol Management Information Base}", + howpublished="RFC 2959 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2959", + pages="1--31", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2959.txt", + key="RFC 2959", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]}, + keywords="RTP, MIB", + doi="10.17487/RFC2959", + } + +@misc{rfc2960, + author="R. Stewart and Q. Xie and K. Morneault and C. Sharp and H. Schwarzbauer and T. Taylor and I. Rytina and M. Kalla and L. Zhang and V. Paxson", + title="{Stream Control Transmission Protocol}", + howpublished="RFC 2960 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2960", + pages="1--134", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4960, updated by RFC 3309", +url="https://www.rfc-editor.org/rfc/rfc2960.txt", + key="RFC 2960", + abstract={This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]}, + keywords="SCTP, IP, internet, transport, packet, network", + doi="10.17487/RFC2960", + } + +@misc{rfc2961, + author="L. Berger and D. Gan and G. Swallow and P. Pan and F. Tommasi and S. Molendini", + title="{RSVP Refresh Overhead Reduction Extensions}", + howpublished="RFC 2961 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2961", + pages="1--34", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5063", +url="https://www.rfc-editor.org/rfc/rfc2961.txt", + key="RFC 2961", + abstract={This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, messages", + doi="10.17487/RFC2961", + } + +@misc{rfc2962, + author="D. Raz and J. Schoenwaelder and B. Sugla", + title="{An SNMP Application Level Gateway for Payload Address Translation}", + howpublished="RFC 2962 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2962", + pages="1--20", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2962.txt", + key="RFC 2962", + abstract={This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. This memo provides information for the Internet community.}, + keywords="simple, network, management, protocol", + doi="10.17487/RFC2962", + } + +@misc{rfc2963, + author="O. Bonaventure and S. De Cnodder", + title="{A Rate Adaptive Shaper for Differentiated Services}", + howpublished="RFC 2963 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2963", + pages="1--19", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2963.txt", + key="RFC 2963", + abstract={This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively. This memo provides information for the Internet community.}, + keywords="RAS, TCP, transmission, control, protocol, diffserv", + doi="10.17487/RFC2963", + } + +@misc{rfc2964, + author="K. Moore and N. Freed", + title="{Use of HTTP State Management}", + howpublished="RFC 2964 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2964", + pages="1--8", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2964.txt", + key="RFC 2964", + abstract={This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="hypertext, transfer, protocol", + doi="10.17487/RFC2964", + } + +@misc{rfc2965, + author="D. Kristol and L. Montulli", + title="{HTTP State Management Mechanism}", + howpublished="RFC 2965 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="2965", + pages="1--26", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6265", +url="https://www.rfc-editor.org/rfc/rfc2965.txt", + key="RFC 2965", + abstract={This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS-TRACK]}, + keywords="hypertext, transfer, protocol", + doi="10.17487/RFC2965", + } + +@misc{rfc2966, + author="T. Li and T. Przygienda and H. Smit", + title="{Domain-wide Prefix Distribution with Two-Level IS-IS}", + howpublished="RFC 2966 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2966", + pages="1--14", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5302", +url="https://www.rfc-editor.org/rfc/rfc2966.txt", + key="RFC 2966", + abstract={This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. This memo provides information for the Internet community.}, + keywords="intermediate, system, routers, loops, IP, internet, protocol", + doi="10.17487/RFC2966", + } + +@misc{rfc2967, + author="L. Daigle and R. Hedberg", + title="{TISDAG - Technical Infrastructure for Swedish Directory Access Gateways}", + howpublished="RFC 2967 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2967", + pages="1--105", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2967.txt", + key="RFC 2967", + abstract={The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. This memo provides information for the Internet community.}, + keywords="single, point, service", + doi="10.17487/RFC2967", + } + +@misc{rfc2968, + author="L. Daigle and T. Eklof", + title="{Mesh of Multiple DAG servers - Results from TISDAG}", + howpublished="RFC 2968 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2968", + pages="1--9", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2968.txt", + key="RFC 2968", + abstract={This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!). The Common Indexing Protocol (CIP) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. This memo provides information for the Internet community.}, + keywords="technical, infrastructure, swedish, directory, access, gateways, mesh, index", + doi="10.17487/RFC2968", + } + +@misc{rfc2969, + author="T. Eklof and L. Daigle", + title="{Wide Area Directory Deployment - Experiences from TISDAG}", + howpublished="RFC 2969 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2969", + pages="1--19", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2969.txt", + key="RFC 2969", + abstract={This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. This memo provides information for the Internet community.}, + keywords="technical, infrastructure, swedish, access, gateways", + doi="10.17487/RFC2969", + } + +@misc{rfc2970, + author="L. Daigle and T. Eklof", + title="{Architecture for Integrated Directory Services - Result from TISDAG}", + howpublished="RFC 2970 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2970", + pages="1--18", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2970.txt", + key="RFC 2970", + abstract={Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use. This memo provides information for the Internet community.}, + keywords="ids, whitepages, technical, infrastructure, swedish, access, gateways", + doi="10.17487/RFC2970", + } + +@misc{rfc2971, + author="T. Showalter", + title="{IMAP4 ID extension}", + howpublished="RFC 2971 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2971", + pages="1--8", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2971.txt", + key="RFC 2971", + abstract={This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK]}, + keywords="internet, message, access, protocol, client, server", + doi="10.17487/RFC2971", + } + +@misc{rfc2972, + author="N. Popp and M. Mealling and L. Masinter and K. Sollins", + title="{Context and Goals for Common Name Resolution}", + howpublished="RFC 2972 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2972", + pages="1--11", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2972.txt", + key="RFC 2972", + abstract={This document establishes the context and goals for a Common Name Resolution Protocol. This memo provides information for the Internet community.}, + keywords="CNRP", + doi="10.17487/RFC2972", + } + +@misc{rfc2973, + author="R. Balay and D. Katz and J. Parker", + title="{IS-IS Mesh Groups}", + howpublished="RFC 2973 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2973", + pages="1--8", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2973.txt", + key="RFC 2973", + abstract={This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This memo provides information for the Internet community.}, + keywords="intermediate, system, PDU, protocol data, unit", + doi="10.17487/RFC2973", + } + +@misc{rfc2974, + author="M. Handley and C. Perkins and E. Whelan", + title="{Session Announcement Protocol}", + howpublished="RFC 2974 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="2974", + pages="1--18", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2974.txt", + key="RFC 2974", + abstract={This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SAP", + doi="10.17487/RFC2974", + } + +@misc{rfc2975, + author="B. Aboba and J. Arkko and D. Harrington", + title="{Introduction to Accounting Management}", + howpublished="RFC 2975 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2975", + pages="1--54", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2975.txt", + key="RFC 2975", + abstract={This document describes and discusses the issues involved in the design of the modern accounting systems. The field of Accounting Management is concerned with the collection the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This memo provides information for the Internet community.}, + keywords="resource, consumption data, cost allocation", + doi="10.17487/RFC2975", + } + +@misc{rfc2976, + author="S. Donovan", + title="{The SIP INFO Method}", + howpublished="RFC 2976 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2976", + pages="1--9", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6086", +url="https://www.rfc-editor.org/rfc/rfc2976.txt", + key="RFC 2976", + abstract={This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. [STANDARDS-TRACK]}, + keywords="session, initiation, protocol, information, extension", + doi="10.17487/RFC2976", + } + +@misc{rfc2977, + author="S. Glass and T. Hiller and S. Jacobs and C. Perkins", + title="{Mobile IP Authentication, Authorization, and Accounting Requirements}", + howpublished="RFC 2977 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2977", + pages="1--27", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2977.txt", + key="RFC 2977", + abstract={This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. This memo provides information for the Internet community.}, + keywords="AAA, internet, protocol", + doi="10.17487/RFC2977", + } + +@misc{rfc2978, + author="N. Freed and J. Postel", + title="{IANA Charset Registration Procedures}", + howpublished="RFC 2978 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="2978", + pages="1--11", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2978.txt", + key="RFC 2978", + abstract={Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="character, set, mime, multipurpose, internet, mail, extensions", + doi="10.17487/RFC2978", + } + +@misc{rfc2979, + author="N. Freed", + title="{Behavior of and Requirements for Internet Firewalls}", + howpublished="RFC 2979 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2979", + pages="1--7", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2979.txt", + key="RFC 2979", + abstract={This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. This memo provides information for the Internet community.}, + keywords="security, intranet, network", + doi="10.17487/RFC2979", + } + +@misc{rfc2980, + author="S. Barber", + title="{Common NNTP Extensions}", + howpublished="RFC 2980 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2980", + pages="1--27", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3977, 4643, 4644, 6048", +url="https://www.rfc-editor.org/rfc/rfc2980.txt", + key="RFC 2980", + abstract={In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. This memo provides information for the Internet community.}, + keywords="network, news, transfer, protocol", + doi="10.17487/RFC2980", + } + +@misc{rfc2981, + author="R. {Kavasseri (Ed.)}", + title="{Event MIB}", + howpublished="RFC 2981 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2981", + pages="1--50", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2981.txt", + key="RFC 2981", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC2981", + } + +@misc{rfc2982, + author="R. {Kavasseri (Ed.)}", + title="{Distributed Management Expression MIB}", + howpublished="RFC 2982 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2982", + pages="1--41", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2982.txt", + key="RFC 2982", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. [STANDARDS-TRACK]}, + keywords="information, base", + doi="10.17487/RFC2982", + } + +@misc{rfc2983, + author="D. Black", + title="{Differentiated Services and Tunnels}", + howpublished="RFC 2983 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2983", + pages="1--14", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2983.txt", + key="RFC 2983", + abstract={This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms. This memo provides information for the Internet community.}, + keywords="internet, protocol, encapsulation", + doi="10.17487/RFC2983", + } + +@misc{rfc2984, + author="C. Adams", + title="{Use of the CAST-128 Encryption Algorithm in CMS}", + howpublished="RFC 2984 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2984", + pages="1--6", + year=2000, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2984.txt", + key="RFC 2984", + abstract={This document specifies how to incorporate CAST-128 into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. [STANDARDS-TRACK]}, + keywords="cryptographic, message, syntax, security, cipher", + doi="10.17487/RFC2984", + } + +@misc{rfc2985, + author="M. Nystrom and B. Kaliski", + title="{PKCS \#9: Selected Object Classes and Attribute Types Version 2.0}", + howpublished="RFC 2985 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2985", + pages="1--42", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2985.txt", + key="RFC 2985", + abstract={This memo represents a republication of PKCS \#9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.}, + keywords="public-key, cryptography, standards, LDAP, lightweight, directory, access, protocol", + doi="10.17487/RFC2985", + } + +@misc{rfc2986, + author="M. Nystrom and B. Kaliski", + title="{PKCS \#10: Certification Request Syntax Specification Version 1.7}", + howpublished="RFC 2986 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2986", + pages="1--14", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5967", +url="https://www.rfc-editor.org/rfc/rfc2986.txt", + key="RFC 2986", + abstract={This memo represents a republication of PKCS \#10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS \#9 v2.0 or the PKCS \#10 v1.7 document. This memo provides information for the Internet community.}, + keywords="public-key, cryptography, standards, PKCS-10, public, key, distinguished, name, encryption, data", + doi="10.17487/RFC2986", + } + +@misc{rfc2987, + author="P. Hoffman", + title="{Registration of Charset and Languages Media Features Tags}", + howpublished="RFC 2987 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2987", + pages="1--6", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2987.txt", + key="RFC 2987", + abstract={This document contains the registration for two media feature tags: ``charset'' and ``language''. [STANDARDS-TRACK]}, + keywords="character, sets, human, languages, devices", + doi="10.17487/RFC2987", + } + +@misc{rfc2988, + author="V. Paxson and M. Allman", + title="{Computing TCP's Retransmission Timer}", + howpublished="RFC 2988 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2988", + pages="1--8", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6298", +url="https://www.rfc-editor.org/rfc/rfc2988.txt", + key="RFC 2988", + abstract={This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS-TRACK]}, + keywords="transmission, control, protocol, algorithm", + doi="10.17487/RFC2988", + } + +@misc{rfc2989, + author="B. Aboba and P. Calhoun and S. Glass and T. Hiller and P. McCann and H. Shiino and P. Walsh and G. Zorn and G. Dommety and C. Perkins and B. Patil and D. Mitton and S. Manning and M. Beadles and X. Chen and S. Sivalingham and A. Hameed and M. Munson and S. Jacobs and B. Lim and B. Hirschman and R. Hsu and H. Koo and M. Lipford and E. Campbell and Y. Xu and S. Baba and E. Jaques", + title="{Criteria for Evaluating AAA Protocols for Network Access}", + howpublished="RFC 2989 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2989", + pages="1--28", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2989.txt", + key="RFC 2989", + abstract={This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. This memo provides information for the Internet community.}, + keywords="authentication, authorization, accounting", + doi="10.17487/RFC2989", + } + +@misc{rfc2990, + author="G. Huston", + title="{Next Steps for the IP QoS Architecture}", + howpublished="RFC 2990 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2990", + pages="1--24", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2990.txt", + key="RFC 2990", + abstract={This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. This memo provides information for the Internet community.}, + keywords="internet, protocol, quality of service, end-to-end", + doi="10.17487/RFC2990", + } + +@misc{rfc2991, + author="D. Thaler and C. Hopps", + title="{Multipath Issues in Unicast and Multicast Next-Hop Selection}", + howpublished="RFC 2991 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2991", + pages="1--9", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2991.txt", + key="RFC 2991", + abstract={The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community.}, + keywords="routing, forwarding, packets, ECMP", + doi="10.17487/RFC2991", + } + +@misc{rfc2992, + author="C. Hopps", + title="{Analysis of an Equal-Cost Multi-Path Algorithm}", + howpublished="RFC 2992 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2992", + pages="1--8", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2992.txt", + key="RFC 2992", + abstract={Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community.}, + keywords="ECMP, routing, packets, forwarding", + doi="10.17487/RFC2992", + } + +@misc{rfc2993, + author="T. Hain", + title="{Architectural Implications of NAT}", + howpublished="RFC 2993 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2993", + pages="1--29", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2993.txt", + key="RFC 2993", + abstract={This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community.}, + keywords="network, address, translation", + doi="10.17487/RFC2993", + } + +@misc{rfc2994, + author="H. Ohta and M. Matsui", + title="{A Description of the MISTY1 Encryption Algorithm}", + howpublished="RFC 2994 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2994", + pages="1--10", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2994.txt", + key="RFC 2994", + abstract={This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. This memo provides information for the Internet community.}, + keywords="cryptosystem, security, data, stream", + doi="10.17487/RFC2994", + } + +@misc{rfc2995, + author="H. {Lu (Ed.)} and I. Faynberg and J. Voelker and M. Weissman and W. Zhang and S. Rhim and J. Hwang and S. Ago and S. Moeenuddin and S. Hadvani and S. Nyckelgard and J. Yoakum and L. Robart", + title="{Pre-Spirits Implementations of PSTN-initiated Services}", + howpublished="RFC 2995 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2995", + pages="1--44", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2995.txt", + key="RFC 2995", + abstract={This document describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN. This memo provides information for the Internet community.}, + keywords="public, switched, telephone, network", + doi="10.17487/RFC2995", + } + +@misc{rfc2996, + author="Y. Bernet", + title="{Format of the RSVP DCLASS Object}", + howpublished="RFC 2996 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2996", + pages="1--9", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2996.txt", + key="RFC 2996", + abstract={This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, QoS, Quality of Service", + doi="10.17487/RFC2996", + } + +@misc{rfc2997, + author="Y. Bernet and A. Smith and B. Davie", + title="{Specification of the Null Service Type}", + howpublished="RFC 2997 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="2997", + pages="1--12", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2997.txt", + key="RFC 2997", + abstract={The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, QoS, Quality of Service", + doi="10.17487/RFC2997", + } + +@misc{rfc2998, + author="Y. Bernet and P. Ford and R. Yavatkar and F. Baker and L. Zhang and M. Speer and R. Braden and B. Davie and J. Wroclawski and E. Felstaine", + title="{A Framework for Integrated Services Operation over Diffserv Networks}", + howpublished="RFC 2998 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2998", + pages="1--31", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2998.txt", + key="RFC 2998", + abstract={This document describes a framework by which Integrated Services may be supported over Diffserv networks. This memo provides information for the Internet community.}, + keywords="intserv, QoS, Quality of Service, end-to-end", + doi="10.17487/RFC2998", + } + +@misc{rfc2999, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 2900-2999}", + howpublished="RFC 2999 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="2999", + pages="1--23", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc2999.txt", + key="RFC 2999", + doi="10.17487/RFC2999", + } + +@misc{rfc3000, + author="J. Reynolds and R. Braden and S. Ginoza and L. Shiota", + title="{Internet Official Protocol Standards}", + howpublished="RFC 3000 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3000", + pages="1--43", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3300", +url="https://www.rfc-editor.org/rfc/rfc3000.txt", + key="RFC 3000", + abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]}, + doi="10.17487/RFC3000", + } + +@misc{rfc3001, + author="M. Mealling", + title="{A URN Namespace of Object Identifiers}", + howpublished="RFC 3001 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3001", + pages="1--5", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3061", +url="https://www.rfc-editor.org/rfc/rfc3001.txt", + key="RFC 3001", + abstract={This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.}, + keywords="uniform, resource, names, OIDs", + doi="10.17487/RFC3001", + } + +@misc{rfc3002, + author="D. Mitzel", + title="{Overview of 2000 IAB Wireless Internetworking Workshop}", + howpublished="RFC 3002 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3002", + pages="1--42", + year=2000, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3002.txt", + key="RFC 3002", + abstract={This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. This memo provides information for the Internet community.}, + keywords="internet, architecture, board", + doi="10.17487/RFC3002", + } + +@misc{rfc3003, + author="M. Nilsson", + title="{The audio/mpeg Media Type}", + howpublished="RFC 3003 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3003", + pages="1--5", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3003.txt", + key="RFC 3003", + abstract={The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS-TRACK]}, + keywords="MIME, multipurpose, internet, mail, extensions", + doi="10.17487/RFC3003", + } + +@misc{rfc3004, + author="G. Stump and R. Droms and Y. Gu and R. Vyaghrapuri and A. Demirtjis and B. Beser and J. Privat", + title="{The User Class Option for DHCP}", + howpublished="RFC 3004 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3004", + pages="1--6", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3004.txt", + key="RFC 3004", + abstract={This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol", + doi="10.17487/RFC3004", + } + +@misc{rfc3005, + author="S. Harris", + title="{IETF Discussion List Charter}", + howpublished="RFC 3005 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3005", + pages="1--3", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3005.txt", + key="RFC 3005", + abstract={The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, engineering, task, force", + doi="10.17487/RFC3005", + } + +@misc{rfc3006, + author="B. Davie and C. Iturralde and D. Oran and S. Casner and J. Wroclawski", + title="{Integrated Services in the Presence of Compressible Flows}", + howpublished="RFC 3006 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3006", + pages="1--13", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3006.txt", + key="RFC 3006", + abstract={This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. [STANDARDS-TRACK]}, + keywords="routing, resource, allocation, int-serv", + doi="10.17487/RFC3006", + } + +@misc{rfc3007, + author="B. Wellington", + title="{Secure Domain Name System (DNS) Dynamic Update}", + howpublished="RFC 3007 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3007", + pages="1--9", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3007.txt", + key="RFC 3007", + abstract={This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]}, + keywords="security, authentication, validation, DNSSEC", + doi="10.17487/RFC3007", + } + +@misc{rfc3008, + author="B. Wellington", + title="{Domain Name System Security (DNSSEC) Signing Authority}", + howpublished="RFC 3008 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3008", + pages="1--7", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4035, 4033, 4034, updated by RFC 3658", +url="https://www.rfc-editor.org/rfc/rfc3008.txt", + key="RFC 3008", + abstract={This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. [STANDARDS-TRACK]}, + keywords="DNSSEC, authentication, validation, SIG, signature", + doi="10.17487/RFC3008", + } + +@misc{rfc3009, + author="J. Rosenberg and H. Schulzrinne", + title="{Registration of parityfec MIME types}", + howpublished="RFC 3009 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3009", + pages="1--10", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5109", +url="https://www.rfc-editor.org/rfc/rfc3009.txt", + key="RFC 3009", + abstract={The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. [STANDARDS-TRACK]}, + keywords="media-type, multimedia, internet, mail, extensions", + doi="10.17487/RFC3009", + } + +@misc{rfc3010, + author="S. Shepler and B. Callaghan and D. Robinson and R. Thurlow and C. Beame and M. Eisler and D. Noveck", + title="{NFS version 4 Protocol}", + howpublished="RFC 3010 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3010", + pages="1--212", + year=2000, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3530", +url="https://www.rfc-editor.org/rfc/rfc3010.txt", + key="RFC 3010", + abstract={NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [STANDARDS-TRACK]}, + keywords="NFSv4, network, file, system", + doi="10.17487/RFC3010", + } + +@misc{rfc3011, + author="G. Waters", + title="{The IPv4 Subnet Selection Option for DHCP}", + howpublished="RFC 3011 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3011", + pages="1--7", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3011.txt", + key="RFC 3011", + abstract={This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS-TRACK]}, + keywords="internet, protocol, dynamic, host, configuration", + doi="10.17487/RFC3011", + } + +@misc{rfc3012, + author="C. Perkins and P. Calhoun", + title="{Mobile IPv4 Challenge/Response Extensions}", + howpublished="RFC 3012 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3012", + pages="1--17", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4721", +url="https://www.rfc-editor.org/rfc/rfc3012.txt", + key="RFC 3012", + abstract={In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. [STANDARDS-TRACK]}, + keywords="internet, protocol, authentication, foreign, agent", + doi="10.17487/RFC3012", + } + +@misc{rfc3013, + author="T. Killalea", + title="{Recommended Internet Service Provider Security Services and Procedures}", + howpublished="RFC 3013 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3013", + pages="1--13", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3013.txt", + key="RFC 3013", + abstract={The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="ISPs", + doi="10.17487/RFC3013", + } + +@misc{rfc3014, + author="R. Kavasseri", + title="{Notification Log MIB}", + howpublished="RFC 3014 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3014", + pages="1--26", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3014.txt", + key="RFC 3014", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC3014", + } + +@misc{rfc3015, + author="F. Cuervo and N. Greene and A. Rayhan and C. Huitema and B. Rosen and J. Segers", + title="{Megaco Protocol Version 1.0}", + howpublished="RFC 3015 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3015", + pages="1--179", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3525", +url="https://www.rfc-editor.org/rfc/rfc3015.txt", + key="RFC 3015", + abstract={This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. [STANDARDS-TRACK]}, + keywords="MEGACO, H.248, media, gateway, control", + doi="10.17487/RFC3015", + } + +@misc{rfc3016, + author="Y. Kikuchi and T. Nomura and S. Fukunaga and Y. Matsui and H. Kimata", + title="{RTP Payload Format for MPEG-4 Audio/Visual Streams}", + howpublished="RFC 3016 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3016", + pages="1--21", + year=2000, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6416", +url="https://www.rfc-editor.org/rfc/rfc3016.txt", + key="RFC 3016", + abstract={This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. [STANDARDS-TRACK]}, + keywords="real-time transport, protocol, media-type", + doi="10.17487/RFC3016", + } + +@misc{rfc3017, + author="M. Riegel and G. Zorn", + title="{XML DTD for Roaming Access Phone Book}", + howpublished="RFC 3017 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3017", + pages="1--33", + year=2000, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3017.txt", + key="RFC 3017", + abstract={This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. [STANDARDS-TRACK]}, + keywords="extensible, markup, language, document, type, declaration", + doi="10.17487/RFC3017", + } + +@misc{rfc3018, + author="A. Bogdanov", + title="{Unified Memory Space Protocol Specification}", + howpublished="RFC 3018 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3018", + pages="1--81", + year=2000, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3018.txt", + key="RFC 3018", + abstract={This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. This memo defines an Experimental Protocol for the Internet community.}, + keywords="UMSP, network, connection-oriented", + doi="10.17487/RFC3018", + } + +@misc{rfc3019, + author="B. Haberman and R. Worzella", + title="{IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol}", + howpublished="RFC 3019 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3019", + pages="1--15", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5519", +url="https://www.rfc-editor.org/rfc/rfc3019.txt", + key="RFC 3019", + abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [STANDARDS-TRACK]}, + keywords="IPv6, MIB, MLD", + doi="10.17487/RFC3019", + } + +@misc{rfc3020, + author="P. Pate and B. Lynch and K. Rehbehn", + title="{Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function}", + howpublished="RFC 3020 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3020", + pages="1--36", + year=2000, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3020.txt", + key="RFC 3020", + abstract={This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. [STANDARDS-TRACK]}, + keywords="MIB, management, information, base", + doi="10.17487/RFC3020", + } + +@misc{rfc3021, + author="A. Retana and R. White and V. Fuller and D. McPherson", + title="{Using 31-Bit Prefixes on IPv4 Point-to-Point Links}", + howpublished="RFC 3021 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3021", + pages="1--10", + year=2000, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3021.txt", + key="RFC 3021", + abstract={With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK]}, + keywords="internet, protocol, addresses, subnet masks", + doi="10.17487/RFC3021", + } + +@misc{rfc3022, + author="P. Srisuresh and K. Egevang", + title="{Traditional IP Network Address Translator (Traditional NAT)}", + howpublished="RFC 3022 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3022", + pages="1--16", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3022.txt", + key="RFC 3022", + abstract={The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community.}, + keywords="internet, protocol, ports, private", + doi="10.17487/RFC3022", + } + +@misc{rfc3023, + author="M. Murata and S. St. Laurent and D. Kohn", + title="{XML Media Types}", + howpublished="RFC 3023 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3023", + pages="1--39", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7303, updated by RFC 6839", +url="https://www.rfc-editor.org/rfc/rfc3023.txt", + key="RFC 3023", + abstract={This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]}, + keywords="extensible, markup, language, web, authority, hypertext, transfer, protocol", + doi="10.17487/RFC3023", + } + +@misc{rfc3024, + author="G. {Montenegro (Ed.)}", + title="{Reverse Tunneling for Mobile IP, revised}", + howpublished="RFC 3024 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3024", + pages="1--30", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3024.txt", + key="RFC 3024", + abstract={This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. [STANDARDS-TRACK]}, + keywords="internet, protocol, node, care-of-address", + doi="10.17487/RFC3024", + } + +@misc{rfc3025, + author="G. Dommety and K. Leung", + title="{Mobile IP Vendor/Organization-Specific Extensions}", + howpublished="RFC 3025 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3025", + pages="1--8", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3115", +url="https://www.rfc-editor.org/rfc/rfc3025.txt", + key="RFC 3025", + abstract={This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]}, + keywords="internet, protocol", + doi="10.17487/RFC3025", + } + +@misc{rfc3026, + author="R. Blane", + title="{Liaison to IETF/ISOC on ENUM}", + howpublished="RFC 3026 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3026", + pages="1--6", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3026.txt", + key="RFC 3026", + abstract={Working Party 1/2, of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. This memo provides information for the Internet community.}, + keywords="dns, domain, name, system, internet, security, engineering, task force, E.164, number", + doi="10.17487/RFC3026", + } + +@misc{rfc3027, + author="M. Holdrege and P. Srisuresh", + title="{Protocol Complications with the IP Network Address Translator}", + howpublished="RFC 3027 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3027", + pages="1--20", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3027.txt", + key="RFC 3027", + abstract={The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. This memo provides information for the Internet community.}, + keywords="IP, internet, protocol, network, address, translator", + doi="10.17487/RFC3027", + } + +@misc{rfc3028, + author="T. Showalter", + title="{Sieve: A Mail Filtering Language}", + howpublished="RFC 3028 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3028", + pages="1--36", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5228, 5429", +url="https://www.rfc-editor.org/rfc/rfc3028.txt", + key="RFC 3028", + abstract={This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]}, + keywords="client, server", + doi="10.17487/RFC3028", + } + +@misc{rfc3029, + author="C. Adams and P. Sylvester and M. Zolotarev and R. Zuccherato", + title="{Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols}", + howpublished="RFC 3029 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3029", + pages="1--51", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3029.txt", + key="RFC 3029", + abstract={This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DVCS, TTP, trusted third party", + doi="10.17487/RFC3029", + } + +@misc{rfc3030, + author="G. Vaudreuil", + title="{SMTP Service Extensions for Transmission of Large and Binary MIME Messages}", + howpublished="RFC 3030 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3030", + pages="1--12", + year=2000, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3030.txt", + key="RFC 3030", + abstract={This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]}, + keywords="simple, mail, transfer, protocol, multipurpose, interent", + doi="10.17487/RFC3030", + } + +@misc{rfc3031, + author="E. Rosen and A. Viswanathan and R. Callon", + title="{Multiprotocol Label Switching Architecture}", + howpublished="RFC 3031 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3031", + pages="1--61", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6178, 6790", +url="https://www.rfc-editor.org/rfc/rfc3031.txt", + key="RFC 3031", + abstract={This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]}, + keywords="MPLS", + doi="10.17487/RFC3031", + } + +@misc{rfc3032, + author="E. Rosen and D. Tappan and G. Fedorkow and Y. Rekhter and D. Farinacci and T. Li and A. Conta", + title="{MPLS Label Stack Encoding}", + howpublished="RFC 3032 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3032", + pages="1--23", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3443, 4182, 5332, 3270, 5129, 5462, 5586, 7274", +url="https://www.rfc-editor.org/rfc/rfc3032.txt", + key="RFC 3032", + abstract={This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]}, + keywords="multi-protocol, label, switching", + doi="10.17487/RFC3032", + } + +@misc{rfc3033, + author="M. Suzuki", + 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}", + howpublished="RFC 3033 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3033", + pages="1--25", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3033.txt", + key="RFC 3033", + abstract={The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. [STANDARDS-TRACK]}, + keywords="IP", + doi="10.17487/RFC3033", + } + +@misc{rfc3034, + author="A. Conta and P. Doolan and A. Malis", + title="{Use of Label Switching on Frame Relay Networks Specification}", + howpublished="RFC 3034 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3034", + pages="1--24", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3034.txt", + key="RFC 3034", + abstract={This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS-TRACK]}, + keywords="MPLS, multi-protocol", + doi="10.17487/RFC3034", + } + +@misc{rfc3035, + author="B. Davie and J. Lawrence and K. McCloghrie and E. Rosen and G. Swallow and Y. Rekhter and P. Doolan", + title="{MPLS using LDP and ATM VC Switching}", + howpublished="RFC 3035 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3035", + pages="1--20", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3035.txt", + key="RFC 3035", + abstract={This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. [STANDARDS-TRACK]}, + keywords="multi-protocol, label, switching, asynchronous, transfer, mode, distribution, protocol", + doi="10.17487/RFC3035", + } + +@misc{rfc3036, + author="L. Andersson and P. Doolan and N. Feldman and A. Fredette and B. Thomas", + title="{LDP Specification}", + howpublished="RFC 3036 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3036", + pages="1--132", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5036", +url="https://www.rfc-editor.org/rfc/rfc3036.txt", + key="RFC 3036", + abstract={A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]}, + keywords="label, distribution, protocol", + doi="10.17487/RFC3036", + } + +@misc{rfc3037, + author="B. Thomas and E. Gray", + title="{LDP Applicability}", + howpublished="RFC 3037 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3037", + pages="1--7", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3037.txt", + key="RFC 3037", + abstract={A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This memo provides information for the Internet community.}, + keywords="label, distribution, protocol", + doi="10.17487/RFC3037", + } + +@misc{rfc3038, + author="K. Nagami and Y. Katsube and N. Demizu and H. Esaki and P. Doolan", + title="{VCID Notification over ATM link for LDP}", + howpublished="RFC 3038 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3038", + pages="1--19", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7274", +url="https://www.rfc-editor.org/rfc/rfc3038.txt", + key="RFC 3038", + abstract={This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS-TRACK]}, + keywords="asynchronous, transfer, mode, label, distribution, protocol", + doi="10.17487/RFC3038", + } + +@misc{rfc3039, + author="S. Santesson and W. Polk and P. Barzin and M. Nystrom", + title="{Internet X.509 Public Key Infrastructure Qualified Certificates Profile}", + howpublished="RFC 3039 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3039", + pages="1--35", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3739", +url="https://www.rfc-editor.org/rfc/rfc3039.txt", + key="RFC 3039", + abstract={This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The goal of this document is to define a general syntax independent of local legal requirements. [STANDARDS-TRACK]}, + keywords="syntax", + doi="10.17487/RFC3039", + } + +@misc{rfc3040, + author="I. Cooper and I. Melve and G. Tomlinson", + title="{Internet Web Replication and Caching Taxonomy}", + howpublished="RFC 3040 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3040", + pages="1--32", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3040.txt", + key="RFC 3040", + abstract={This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. This memo provides information for the Internet community.}, + keywords="infrastructure, www, world, wide", + doi="10.17487/RFC3040", + } + +@misc{rfc3041, + author="T. Narten and R. Draves", + title="{Privacy Extensions for Stateless Address Autoconfiguration in IPv6}", + howpublished="RFC 3041 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3041", + pages="1--17", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4941", +url="https://www.rfc-editor.org/rfc/rfc3041.txt", + key="RFC 3041", + abstract={This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]}, + keywords="internet, protocol, interface, identifier", + doi="10.17487/RFC3041", + } + +@misc{rfc3042, + author="M. Allman and H. Balakrishnan and S. Floyd", + title="{Enhancing TCP's Loss Recovery Using Limited Transmit}", + howpublished="RFC 3042 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3042", + pages="1--9", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3042.txt", + key="RFC 3042", + abstract={This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS-TRACK]}, + keywords="transmission, control, protocol", + doi="10.17487/RFC3042", + } + +@misc{rfc3043, + author="M. Mealling", + title="{The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations}", + howpublished="RFC 3043 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3043", + pages="1--5", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3043.txt", + key="RFC 3043", + abstract={This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community.}, + keywords="uniform, resource, name", + doi="10.17487/RFC3043", + } + +@misc{rfc3044, + author="S. Rozenfeld", + title="{Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace}", + howpublished="RFC 3044 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3044", + pages="1--15", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8254", +url="https://www.rfc-editor.org/rfc/rfc3044.txt", + key="RFC 3044", + abstract={This document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier. This memo provides information for the Internet community.}, + keywords="serials, identifier", + doi="10.17487/RFC3044", + } + +@misc{rfc3045, + author="M. Meredith", + title="{Storing Vendor Information in the LDAP root DSE}", + howpublished="RFC 3045 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3045", + pages="1--6", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3045.txt", + key="RFC 3045", + abstract={This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol, DSA-specific, entry", + doi="10.17487/RFC3045", + } + +@misc{rfc3046, + author="M. Patrick", + title="{DHCP Relay Agent Information Option}", + howpublished="RFC 3046 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3046", + pages="1--14", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6607", +url="https://www.rfc-editor.org/rfc/rfc3046.txt", + key="RFC 3046", + abstract={Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such ``public'' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol", + doi="10.17487/RFC3046", + } + +@misc{rfc3047, + author="P. Luthi", + title="{RTP Payload Format for ITU-T Recommendation G.722.1}", + howpublished="RFC 3047 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3047", + pages="1--8", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5577", +url="https://www.rfc-editor.org/rfc/rfc3047.txt", + key="RFC 3047", + abstract={This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use of G.722.1 with MIME and SDP. [STANDARDS-TRACK]}, + keywords="international, telecommunication, union, real-time, transport, protocol", + doi="10.17487/RFC3047", + } + +@misc{rfc3048, + author="B. Whetten and L. Vicisano and R. Kermode and M. Handley and S. Floyd and M. Luby", + title="{Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer}", + howpublished="RFC 3048 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3048", + pages="1--20", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3048.txt", + key="RFC 3048", + abstract={This document describes a framework for the standardization of bulk-data reliable multicast transport. This memo provides information for the Internet community.}, + keywords="RMT, protocol, core", + doi="10.17487/RFC3048", + } + +@misc{rfc3049, + author="J. Naugle and K. Kasthurirangan and G. Ledford", + title="{TN3270E Service Location and Session Balancing}", + howpublished="RFC 3049 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3049", + pages="1--21", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3049.txt", + key="RFC 3049", + abstract={This document discusses the implementation of Service Location Protocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. [STANDARDS-TRACK]}, + keywords="SLP", + doi="10.17487/RFC3049", + } + +@misc{rfc3050, + author="J. Lennox and H. Schulzrinne and J. Rosenberg", + title="{Common Gateway Interface for SIP}", + howpublished="RFC 3050 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3050", + pages="1--35", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3050.txt", + key="RFC 3050", + abstract={This document defines a SIP CGI interface for providing SIP services on a SIP server. This memo provides information for the Internet community.}, + keywords="session, initiation, protocol", + doi="10.17487/RFC3050", + } + +@misc{rfc3051, + author="J. Heath and J. Border", + title="{IP Payload Compression Using ITU-T V.44 Packet Method}", + howpublished="RFC 3051 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3051", + pages="1--8", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3051.txt", + key="RFC 3051", + abstract={This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community.}, + keywords="internet, protocol, international, telecommunication, union", + doi="10.17487/RFC3051", + } + +@misc{rfc3052, + author="M. Eder and S. Nag", + title="{Service Management Architectures Issues and Review}", + howpublished="RFC 3052 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3052", + pages="1--12", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3052.txt", + key="RFC 3052", + abstract={The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. This memo provides information for the Internet community.}, + keywords="framework, packets, network", + doi="10.17487/RFC3052", + } + +@misc{rfc3053, + author="A. Durand and P. Fasano and I. Guardini and D. Lento", + title="{IPv6 Tunnel Broker}", + howpublished="RFC 3053 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3053", + pages="1--13", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3053.txt", + key="RFC 3053", + abstract={The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng \& NGtrans interim meeting in February 1999. This memo provides information for the Internet community.}, + keywords="internet, protocol, infrastructure", + doi="10.17487/RFC3053", + } + +@misc{rfc3054, + author="P. Blatherwick and R. Bell and P. Holland", + title="{Megaco IP Phone Media Gateway Application Profile}", + howpublished="RFC 3054 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3054", + pages="1--14", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3054.txt", + key="RFC 3054", + abstract={This document specifies a particular application of the Megaco/H.248 Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. This memo provides information for the Internet community.}, + keywords="internet, protocol, H.248, telephone, MG", + doi="10.17487/RFC3054", + } + +@misc{rfc3055, + author="M. Krishnaswamy and D. Romascanu", + title="{Management Information Base for the PINT Services Architecture}", + howpublished="RFC 3055 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3055", + pages="1--21", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3055.txt", + key="RFC 3055", + abstract={This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS-TRACK]}, + keywords="MIB, PSTN/Internet, interworking", + doi="10.17487/RFC3055", + } + +@misc{rfc3056, + author="B. Carpenter and K. Moore", + title="{Connection of IPv6 Domains via IPv4 Clouds}", + howpublished="RFC 3056 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3056", + pages="1--23", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3056.txt", + key="RFC 3056", + abstract={This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]}, + keywords="internet, protocol, wide area, network, unicast, point-to-point", + doi="10.17487/RFC3056", + } + +@misc{rfc3057, + author="K. Morneault and S. Rengasami and M. Kalla and G. Sidebottom", + title="{ISDN Q.921-User Adaptation Layer}", + howpublished="RFC 3057 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3057", + pages="1--66", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4233, updated by RFC 3807", +url="https://www.rfc-editor.org/rfc/rfc3057.txt", + key="RFC 3057", + abstract={This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). [STANDARDS-TRACK]}, + keywords="SCTP, signaling, media, gateway, interface", + doi="10.17487/RFC3057", + } + +@misc{rfc3058, + author="S. Teiwes and P. Hartmann and D. Kuenzi", + title="{Use of the IDEA Encryption Algorithm in CMS}", + howpublished="RFC 3058 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3058", + pages="1--8", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3058.txt", + key="RFC 3058", + abstract={This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. This memo provides information for the Internet community.}, + keywords="international, data encryption, algorithm, cryptic message, syntax, s/mime, multipurpose internet, mail extensions", + doi="10.17487/RFC3058", + } + +@misc{rfc3059, + author="E. Guttman", + title="{Attribute List Extension for the Service Location Protocol}", + howpublished="RFC 3059 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3059", + pages="1--6", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3059.txt", + key="RFC 3059", + abstract={This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. [STANDARDS-TRACK]}, + keywords="SLPv2, messages, user agent", + doi="10.17487/RFC3059", + } + +@misc{rfc3060, + author="B. Moore and E. Ellesson and J. Strassner and A. Westerinen", + title="{Policy Core Information Model -- Version 1 Specification}", + howpublished="RFC 3060 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3060", + pages="1--100", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3460", +url="https://www.rfc-editor.org/rfc/rfc3060.txt", + key="RFC 3060", + abstract={This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS-TRACK]}, + keywords="CIM, common, schema, object-oriented", + doi="10.17487/RFC3060", + } + +@misc{rfc3061, + author="M. Mealling", + title="{A URN Namespace of Object Identifiers}", + howpublished="RFC 3061 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3061", + pages="1--6", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3061.txt", + key="RFC 3061", + abstract={This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.}, + keywords="uniform, resource, names, OIDs", + doi="10.17487/RFC3061", + } + +@misc{rfc3062, + author="K. Zeilenga", + title="{LDAP Password Modify Extended Operation}", + howpublished="RFC 3062 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3062", + pages="1--6", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3062.txt", + key="RFC 3062", + abstract={This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol", + doi="10.17487/RFC3062", + } + +@misc{rfc3063, + author="Y. Ohba and Y. Katsube and E. Rosen and P. Doolan", + title="{MPLS Loop Prevention Mechanism}", + howpublished="RFC 3063 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3063", + pages="1--44", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3063.txt", + key="RFC 3063", + abstract={This paper presents a simple mechanism, based on ``threads'', which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. This memo defines an Experimental Protocol for the Internet community.}, + keywords="multiprotocol, label, switching, path, LSPs", + doi="10.17487/RFC3063", + } + +@misc{rfc3064, + author="B. Foster", + title="{MGCP CAS Packages}", + howpublished="RFC 3064 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3064", + pages="1--56", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3064.txt", + key="RFC 3064", + abstract={This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. This memo provides information for the Internet community.}, + keywords="media, gateway, controllers", + doi="10.17487/RFC3064", + } + +@misc{rfc3065, + author="P. Traina and D. McPherson and J. Scudder", + title="{Autonomous System Confederations for BGP}", + howpublished="RFC 3065 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3065", + pages="1--11", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5065", +url="https://www.rfc-editor.org/rfc/rfc3065.txt", + key="RFC 3065", + abstract={This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the ``full mesh'' requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS-TRACK]}, + keywords="BGP-ASC, AS, border, gateway, protocol", + doi="10.17487/RFC3065", + } + +@misc{rfc3066, + author="H. Alvestrand", + title="{Tags for the Identification of Languages}", + howpublished="RFC 3066 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3066", + pages="1--13", + year=2001, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4646, 4647", +url="https://www.rfc-editor.org/rfc/rfc3066.txt", + key="RFC 3066", + abstract={This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Lang-Tag", + doi="10.17487/RFC3066", + } + +@misc{rfc3067, + author="J. Arvidsson and A. Cormack and Y. Demchenko and J. Meijer", + title="{TERENA'S Incident Object Description and Exchange Format Requirements}", + howpublished="RFC 3067 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3067", + pages="1--17", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3067.txt", + key="RFC 3067", + abstract={The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements. This memo provides information for the Internet community.}, + keywords="IEDEF, data, archiving", + doi="10.17487/RFC3067", + } + +@misc{rfc3068, + author="C. Huitema", + title="{An Anycast Prefix for 6to4 Relay Routers}", + howpublished="RFC 3068 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3068", + pages="1--9", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7526", +url="https://www.rfc-editor.org/rfc/rfc3068.txt", + key="RFC 3068", + abstract={This memo introduces a ``6to4 anycast address'' in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding ``6to4 anycast prefix'' will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the ``6to4 relay anycast prefix.'' [STANDARDS-TRACK]}, + keywords="exterior, gateway, protocol, interior, IGP, EGP", + doi="10.17487/RFC3068", + } + +@misc{rfc3069, + author="D. McPherson and B. Dykes", + title="{VLAN Aggregation for Efficient IP Address Allocation}", + howpublished="RFC 3069 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3069", + pages="1--7", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3069.txt", + key="RFC 3069", + abstract={This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. This memo provides information for the Internet community.}, + keywords="virtual, local, area, network, internet, protocol", + doi="10.17487/RFC3069", + } + +@misc{rfc3070, + author="V. Rawat and R. Tio and S. Nanji and R. Verma", + title="{Layer Two Tunneling Protocol (L2TP) over Frame Relay}", + howpublished="RFC 3070 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3070", + pages="1--7", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3070.txt", + key="RFC 3070", + abstract={This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS-TRACK]}, + keywords="L2TP-FR, point-to-point, virtual, switched, circuits, PVCs, SVCs", + doi="10.17487/RFC3070", + } + +@misc{rfc3071, + author="J. Klensin", + title="{Reflections on the DNS, RFC 1591, and Categories of Domains}", + howpublished="RFC 3071 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3071", + pages="1--10", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3071.txt", + key="RFC 3071", + abstract={This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. This memo provides information for the Internet community.}, + keywords="DNS, Policy, Top-Level, TLD", + doi="10.17487/RFC3071", + } + +@misc{rfc3072, + author="M. Wildgrube", + title="{Structured Data Exchange Format (SDXF)}", + howpublished="RFC 3072 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3072", + pages="1--26", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3072.txt", + key="RFC 3072", + abstract={This specification describes an all-purpose interchange format for use as a file format or for net-working. This memo provides information for the Internet community.}, + keywords="chunks, file, datatype", + doi="10.17487/RFC3072", + } + +@misc{rfc3073, + author="J. Collins", + title="{Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration}", + howpublished="RFC 3073 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3073", + pages="1--6", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3073.txt", + key="RFC 3073", + abstract={This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. This memo provides information for the Internet community.}, + keywords="multipurpose, internet, mail, extensions", + doi="10.17487/RFC3073", + } + +@misc{rfc3074, + author="B. Volz and S. Gonczi and T. Lemon and R. Stevens", + title="{DHC Load Balancing Algorithm}", + howpublished="RFC 3074 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3074", + pages="1--10", + year=2001, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3074.txt", + key="RFC 3074", + abstract={This document proposes a method of algorithmic load balancing. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol", + doi="10.17487/RFC3074", + } + +@misc{rfc3075, + author="D. {Eastlake 3rd} and J. Reagle and D. Solo", + title="{XML-Signature Syntax and Processing}", + howpublished="RFC 3075 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3075", + pages="1--64", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3275", +url="https://www.rfc-editor.org/rfc/rfc3075.txt", + key="RFC 3075", + abstract={This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]}, + keywords="extensible, markup, language", + doi="10.17487/RFC3075", + } + +@misc{rfc3076, + author="J. Boyer", + title="{Canonical XML Version 1.0}", + howpublished="RFC 3076 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3076", + pages="1--28", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3076.txt", + key="RFC 3076", + abstract={This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. This memo provides information for the Internet community.}, + keywords="extensible, markup, language", + doi="10.17487/RFC3076", + } + +@misc{rfc3077, + author="E. Duros and W. Dabbous and H. Izumiyama and N. Fujii and Y. Zhang", + title="{A Link-Layer Tunneling Mechanism for Unidirectional Links}", + howpublished="RFC 3077 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3077", + pages="1--25", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3077.txt", + key="RFC 3077", + abstract={This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS-TRACK]}, + keywords="ll, udl, bidirectional, connectivity, ip, internet, protocol", + doi="10.17487/RFC3077", + } + +@misc{rfc3078, + author="G. Pall and G. Zorn", + title="{Microsoft Point-To-Point Encryption (MPPE) Protocol}", + howpublished="RFC 3078 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3078", + pages="1--12", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3078.txt", + key="RFC 3078", + abstract={This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. This memo provides information for the Internet community.}, + keywords="security, ppp", + doi="10.17487/RFC3078", + } + +@misc{rfc3079, + author="G. Zorn", + title="{Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)}", + howpublished="RFC 3079 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3079", + pages="1--21", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3079.txt", + key="RFC 3079", + abstract={This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. This memo provides information for the Internet community.}, + keywords="security, ppp", + doi="10.17487/RFC3079", + } + +@misc{rfc3080, + author="M. Rose", + title="{The Blocks Extensible Exchange Protocol Core}", + howpublished="RFC 3080 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3080", + pages="1--58", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3080.txt", + key="RFC 3080", + abstract={This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS-TRACK]}, + keywords="BEEP, text, binary, messages, kernal", + doi="10.17487/RFC3080", + } + +@misc{rfc3081, + author="M. Rose", + title="{Mapping the BEEP Core onto TCP}", + howpublished="RFC 3081 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3081", + pages="1--8", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3081.txt", + key="RFC 3081", + abstract={This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS-TRACK]}, + keywords="transmission, control, protocol, blocks, extensible, exchange", + doi="10.17487/RFC3081", + } + +@misc{rfc3082, + author="J. Kempf and J. Goldschmidt", + title="{Notification and Subscription for SLP}", + howpublished="RFC 3082 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3082", + pages="1--14", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3082.txt", + key="RFC 3082", + abstract={The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. This memo defines an Experimental Protocol for the Internet community.}, + keywords="service, location, protocol", + doi="10.17487/RFC3082", + } + +@misc{rfc3083, + author="R. Woundy", + title="{Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems}", + howpublished="RFC 3083 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3083", + pages="1--45", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3083.txt", + key="RFC 3083", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over- Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo provides information for the Internet community.}, + keywords="MIB, BPI, data-over-cable, service interface, specifications", + doi="10.17487/RFC3083", + } + +@misc{rfc3084, + author="K. Chan and J. Seligson and D. Durham and S. Gai and K. McCloghrie and S. Herzog and F. Reichmeyer and R. Yavatkar and A. Smith", + title="{COPS Usage for Policy Provisioning (COPS-PR)}", + howpublished="RFC 3084 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3084", + pages="1--34", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3084.txt", + key="RFC 3084", + abstract={This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK]}, + keywords="COPS-PR, common, open, service, security, quality", + doi="10.17487/RFC3084", + } + +@misc{rfc3085, + author="A. Coates and D. Allen and D. Rivers-Moore", + title="{URN Namespace for NewsML Resources}", + howpublished="RFC 3085 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3085", + pages="1--6", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3085.txt", + key="RFC 3085", + abstract={This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. This memo provides information for the Internet community.}, + keywords="uniform, resource, name, newsitems, iptc", + doi="10.17487/RFC3085", + } + +@misc{rfc3086, + author="K. Nichols and B. Carpenter", + title="{Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification}", + howpublished="RFC 3086 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3086", + pages="1--24", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3086.txt", + key="RFC 3086", + abstract={This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community.}, + keywords="diffserv, QoS, quality of service", + doi="10.17487/RFC3086", + } + +@misc{rfc3087, + author="B. Campbell and R. Sparks", + title="{Control of Service Context using SIP Request-URI}", + howpublished="RFC 3087 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3087", + pages="1--39", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3087.txt", + key="RFC 3087", + abstract={This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. This memo provides information for the Internet community.}, + keywords="session, initiation, protocol, uniform, resource, identifier", + doi="10.17487/RFC3087", + } + +@misc{rfc3088, + author="K. Zeilenga", + title="{OpenLDAP Root Service An experimental LDAP referral service}", + howpublished="RFC 3088 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3088", + pages="1--11", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3088.txt", + key="RFC 3088", + abstract={The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the ``OpenLDAP Root Service''. The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. This memo defines an Experimental Protocol for the Internet community.}, + keywords="lightweight, directory, access, protocol, dns, domain, name, system", + doi="10.17487/RFC3088", + } + +@misc{rfc3089, + author="H. Kitamura", + title="{A SOCKS-based IPv6/IPv4 Gateway Mechanism}", + howpublished="RFC 3089 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3089", + pages="1--12", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3089.txt", + key="RFC 3089", + abstract={This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. This memo provides information for the Internet community.}, + keywords="internet, protocol, application, layer", + doi="10.17487/RFC3089", + } + +@misc{rfc3090, + author="E. Lewis", + title="{DNS Security Extension Clarification on Zone Status}", + howpublished="RFC 3090 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3090", + pages="1--11", + year=2001, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFC 3658", +url="https://www.rfc-editor.org/rfc/rfc3090.txt", + key="RFC 3090", + abstract={The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, ``experimentally secure'' status is deprecated. [STANDARDS-TRACK]}, + keywords="domain, name, system, rsa, dsa", + doi="10.17487/RFC3090", + } + +@misc{rfc3091, + author="H. Kennedy", + title="{Pi Digit Generation Protocol}", + howpublished="RFC 3091 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3091", + pages="1--6", + year=2001, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3091.txt", + key="RFC 3091", + abstract={This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.}, + doi="10.17487/RFC3091", + } + +@misc{rfc3092, + author="D. {Eastlake 3rd} and C. Manros and E. Raymond", + title="{Etymology of ``Foo''}", + howpublished="RFC 3092 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3092", + pages="1--14", + year=2001, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3092.txt", + key="RFC 3092", + abstract={Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. This memo provides information for the Internet community.}, + doi="10.17487/RFC3092", + } + +@misc{rfc3093, + author="M. Gaynor and S. Bradner", + title="{Firewall Enhancement Protocol (FEP)}", + howpublished="RFC 3093 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3093", + pages="1--11", + year=2001, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3093.txt", + key="RFC 3093", + abstract={Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. This memo provides information for the Internet community.}, + doi="10.17487/RFC3093", + } + +@misc{rfc3094, + author="D. Sprague and R. Benedyk and D. Brendes and J. Keller", + title="{Tekelec's Transport Adapter Layer Interface}", + howpublished="RFC 3094 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3094", + pages="1--106", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3094.txt", + key="RFC 3094", + abstract={This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. This memo provides information for the Internet community.}, + keywords="signaling, gatewa, circuit, network, internet, protocol", + doi="10.17487/RFC3094", + } + +@misc{rfc3095, + author="C. Bormann and C. Burmeister and M. Degermark and H. Fukushima and H. Hannu and L-E. Jonsson and R. Hakenberg and T. Koren and K. Le and Z. Liu and A. Martensson and A. Miyazaki and K. Svanbro and T. Wiebke and T. Yoshimura and H. Zheng", + title="{RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed}", + howpublished="RFC 3095 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3095", + pages="1--168", + year=2001, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3759, 4815", +url="https://www.rfc-editor.org/rfc/rfc3095.txt", + key="RFC 3095", + abstract={This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]}, + keywords="encapsulating, security, payload, real-time, transport, protocol, user, datagram", + doi="10.17487/RFC3095", + } + +@misc{rfc3096, + author="M. {Degermark (Ed.)}", + title="{Requirements for robust IP/UDP/RTP header compression}", + howpublished="RFC 3096 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3096", + pages="1--8", + year=2001, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3096.txt", + key="RFC 3096", + abstract={This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document ``3GPP TR 23.922'', version 1.0.0 of October 1999, as well as contributions from 3G.IP. This memo provides information for the Internet community.}, + keywords="real-time, transport, internet, protocol, user, datagram", + doi="10.17487/RFC3096", + } + +@misc{rfc3097, + author="R. Braden and L. Zhang", + title="{RSVP Cryptographic Authentication -- Updated Message Type Value}", + howpublished="RFC 3097 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3097", + pages="1--4", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3097.txt", + key="RFC 3097", + abstract={This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS-TRACK]}, + keywords="RSVP, resource, reservation, protocol, security", + doi="10.17487/RFC3097", + } + +@misc{rfc3098, + author="T. Gavin and D. {Eastlake 3rd} and S. Hambridge", + title="{How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to \$\$\$\$\$ MAKE ENEMIES FAST! \$\$\$\$\$}", + howpublished="RFC 3098 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3098", + pages="1--28", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3098.txt", + key="RFC 3098", + abstract={This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. This memo provides information for the Internet community.}, + keywords="internet, marketing, users, service, providers, isps", + doi="10.17487/RFC3098", + } + +@misc{rfc3099, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 3000-3099}", + howpublished="RFC 3099 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3099", + pages="1--25", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3099.txt", + key="RFC 3099", + doi="10.17487/RFC3099", + } + +@misc{rfc3101, + author="P. Murphy", + title="{The OSPF Not-So-Stubby Area (NSSA) Option}", + howpublished="RFC 3101 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3101", + pages="1--33", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3101.txt", + key="RFC 3101", + abstract={This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a ``not-so-stubby'' area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]}, + keywords="OSPF-NSSA, stub, external routes, backward compatible", + doi="10.17487/RFC3101", + } + +@misc{rfc3102, + author="M. Borella and J. Lo and D. Grabelsky and G. Montenegro", + title="{Realm Specific IP: Framework}", + howpublished="RFC 3102 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3102", + pages="1--30", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3102.txt", + key="RFC 3102", + abstract={This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. This memo defines an Experimental Protocol for the Internet community.}, + keywords="RSIP, end-to-end, NAT, addressing, requirements", + doi="10.17487/RFC3102", + } + +@misc{rfc3103, + author="M. Borella and D. Grabelsky and J. Lo and K. Taniguchi", + title="{Realm Specific IP: Protocol Specification}", + howpublished="RFC 3103 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3103", + pages="1--54", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3103.txt", + key="RFC 3103", + abstract={This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. This memo defines an Experimental Protocol for the Internet community.}, + keywords="RSIP, host, gateway, NAT, requirements", + doi="10.17487/RFC3103", + } + +@misc{rfc3104, + author="G. Montenegro and M. Borella", + title="{RSIP Support for End-to-end IPsec}", + howpublished="RFC 3104 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3104", + pages="1--19", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3104.txt", + key="RFC 3104", + abstract={This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security). This memo defines an Experimental Protocol for the Internet community.}, + keywords="realm, specific, internet, protocol, NAT, addressing, requirements", + doi="10.17487/RFC3104", + } + +@misc{rfc3105, + author="J. Kempf and G. Montenegro", + title="{Finding an RSIP Server with SLP}", + howpublished="RFC 3105 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3105", + pages="1--11", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3105.txt", + key="RFC 3105", + abstract={This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. This memo defines an Experimental Protocol for the Internet community.}, + keywords="realm, specific, internet, protocol, service, location, NAT, addressing, requirements", + doi="10.17487/RFC3105", + } + +@misc{rfc3106, + author="D. {Eastlake 3rd} and T. Goldstein", + title="{ECML v1.1: Field Specifications for E-Commerce}", + howpublished="RFC 3106 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3106", + pages="1--20", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4112", +url="https://www.rfc-editor.org/rfc/rfc3106.txt", + key="RFC 3106", + abstract={Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. This memo provides information for the Internet community.}, + keywords="electronic, modeling, language", + doi="10.17487/RFC3106", + } + +@misc{rfc3107, + author="Y. Rekhter and E. Rosen", + title="{Carrying Label Information in BGP-4}", + howpublished="RFC 3107 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3107", + pages="1--8", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8277, updated by RFC 6790", +url="https://www.rfc-editor.org/rfc/rfc3107.txt", + key="RFC 3107", + abstract={This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK]}, + keywords="SDP, asynchronous, transfer, mode, AAL, syntax, adaption, layer", + doi="10.17487/RFC3107", + } + +@misc{rfc3108, + author="R. Kumar and M. Mostafa", + title="{Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections}", + howpublished="RFC 3108 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3108", + pages="1--110", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3108.txt", + key="RFC 3108", + abstract={This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. [STANDARDS-TRACK]}, + keywords="asynchronous, transfer, mode, AAL, syntax, adaption, layer", + doi="10.17487/RFC3108", + } + +@misc{rfc3109, + author="R. Braden and R. Bush and J. Klensin", + title="{Request to Move STD 39 to Historic Status}", + howpublished="RFC 3109 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3109", + pages="1--4", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3109.txt", + key="RFC 3109", + abstract={This memo changes the status of STD 39, BBN Report 1822, ``Specification of the Interconnection of a Host and an IMP'', from Standard to Historic. This memo provides information for the Internet community.}, + keywords="BBN 1822, host, imp, arpanet", + doi="10.17487/RFC3109", + } + +@misc{rfc3110, + author="D. {Eastlake 3rd}", + title="{RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)}", + howpublished="RFC 3110 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3110", + pages="1--7", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6944", +url="https://www.rfc-editor.org/rfc/rfc3110.txt", + key="RFC 3110", + abstract={This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]}, + keywords="RRs, resource, records, security", + doi="10.17487/RFC3110", + } + +@misc{rfc3111, + author="E. Guttman", + title="{Service Location Protocol Modifications for IPv6}", + howpublished="RFC 3111 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3111", + pages="1--13", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3111.txt", + key="RFC 3111", + abstract={This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. [STANDARDS-TRACK]}, + keywords="SLP, internet, protocol", + doi="10.17487/RFC3111", + } + +@misc{rfc3112, + author="K. Zeilenga", + title="{LDAP Authentication Password Schema}", + howpublished="RFC 3112 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3112", + pages="1--9", + year=2001, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3112.txt", + key="RFC 3112", + abstract={This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This memo provides information for the Internet community.}, + keywords="lightweight, directory, access, protocol", + doi="10.17487/RFC3112", + } + +@misc{rfc3113, + author="K. Rosenbrock and R. Sanmugam and S. Bradner and J. Klensin", + title="{3GPP-IETF Standardization Collaboration}", + howpublished="RFC 3113 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3113", + pages="1--7", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3113.txt", + key="RFC 3113", + abstract={This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community.}, + keywords="internet, engineering, task, force, third generation, partnership project", + doi="10.17487/RFC3113", + } + +@misc{rfc3114, + author="W. Nicolls", + title="{Implementing Company Classification Policy with the S/MIME Security Label}", + howpublished="RFC 3114 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3114", + pages="1--14", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3114.txt", + key="RFC 3114", + abstract={This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. This memo provides information for the Internet community.}, + keywords="data, multipurpose, internet mail extensions, access control, information classification, security category", + doi="10.17487/RFC3114", + } + +@misc{rfc3115, + author="G. Dommety and K. Leung", + title="{Mobile IP Vendor/Organization-Specific Extensions}", + howpublished="RFC 3115 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3115", + pages="1--9", + year=2001, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3115.txt", + key="RFC 3115", + abstract={This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]}, + keywords="internet, protocol", + doi="10.17487/RFC3115", + } + +@misc{rfc3116, + author="J. Dunn and C. Martin", + title="{Methodology for ATM Benchmarking}", + howpublished="RFC 3116 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3116", + pages="1--127", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3116.txt", + key="RFC 3116", + abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.}, + keywords="asynchronous, transfer mode, formats, switching", + doi="10.17487/RFC3116", + } + +@misc{rfc3117, + author="M. Rose", + title="{On the Design of Application Protocols}", + howpublished="RFC 3117 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3117", + pages="1--27", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3117.txt", + key="RFC 3117", + abstract={This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community.}, + keywords="beep, bxxp, blocks, extensible, exchange, text, binary", + doi="10.17487/RFC3117", + } + +@misc{rfc3118, + author="R. {Droms (Ed.)} and W. {Arbaugh (Ed.)}", + title="{Authentication for DHCP Messages}", + howpublished="RFC 3118 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3118", + pages="1--17", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3118.txt", + key="RFC 3118", + abstract={This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol, verification", + doi="10.17487/RFC3118", + } + +@misc{rfc3119, + author="R. Finlayson", + title="{A More Loss-Tolerant RTP Payload Format for MP3 Audio}", + howpublished="RFC 3119 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3119", + pages="1--19", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5219", +url="https://www.rfc-editor.org/rfc/rfc3119.txt", + key="RFC 3119", + abstract={This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as ``MP3''). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. [STANDARDS-TRACK]}, + keywords="real-time, protocol, moving, picture, experts, group", + doi="10.17487/RFC3119", + } + +@misc{rfc3120, + author="K. Best and N. Walsh", + title="{A URN Namespace for XML.org}", + howpublished="RFC 3120 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3120", + pages="1--5", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3120.txt", + key="RFC 3120", + abstract={This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.}, + keywords="uniform, resource, name, extensible, markup, language", + doi="10.17487/RFC3120", + } + +@misc{rfc3121, + author="K. Best and N. Walsh", + title="{A URN Namespace for OASIS}", + howpublished="RFC 3121 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3121", + pages="1--7", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3121.txt", + key="RFC 3121", + abstract={This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.}, + keywords="uniform, resource, name, organization for the advancement of structured information standards", + doi="10.17487/RFC3121", + } + +@misc{rfc3122, + author="A. Conta", + title="{Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification}", + howpublished="RFC 3122 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3122", + pages="1--20", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3122.txt", + key="RFC 3122", + abstract={This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. [STANDARDS-TRACK]}, + keywords="internet, protocol, IND, link-layer", + doi="10.17487/RFC3122", + } + +@misc{rfc3123, + author="P. Koch", + title="{A DNS RR Type for Lists of Address Prefixes (APL RR)}", + howpublished="RFC 3123 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3123", + pages="1--8", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3123.txt", + key="RFC 3123", + abstract={The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type ``APL'' for address prefix lists. This memo defines an Experimental Protocol for the Internet community.}, + keywords="domain, name, system, resource, record", + doi="10.17487/RFC3123", + } + +@misc{rfc3124, + author="H. Balakrishnan and S. Seshan", + title="{The Congestion Manager}", + howpublished="RFC 3124 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3124", + pages="1--22", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3124.txt", + key="RFC 3124", + abstract={This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS-TRACK]}, + keywords="network, stream, end-system module", + doi="10.17487/RFC3124", + } + +@misc{rfc3125, + author="J. Ross and D. Pinkas and N. Pope", + title="{Electronic Signature Policies}", + howpublished="RFC 3125 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3125", + pages="1--44", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3125.txt", + key="RFC 3125", + abstract={This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. This memo defines an Experimental Protocol for the Internet community.}, + keywords="signer, purchase, contract, invoice, transactions, applications", + doi="10.17487/RFC3125", + } + +@misc{rfc3126, + author="D. Pinkas and J. Ross and N. Pope", + title="{Electronic Signature Formats for long term electronic signatures}", + howpublished="RFC 3126 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3126", + pages="1--84", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5126", +url="https://www.rfc-editor.org/rfc/rfc3126.txt", + key="RFC 3126", + abstract={This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). This memo provides information for the Internet community.}, + keywords="purchase, contract, invoice, application, smart cards, data", + doi="10.17487/RFC3126", + } + +@misc{rfc3127, + author="D. Mitton and M. St.Johns and S. Barkley and D. Nelson and B. Patil and M. Stevens and B. Wolff", + title="{Authentication, Authorization, and Accounting: Protocol Evaluation}", + howpublished="RFC 3127 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3127", + pages="1--84", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3127.txt", + key="RFC 3127", + abstract={This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. This memo provides information for the Internet community.}, + keywords="AAA, network, access, requirements", + doi="10.17487/RFC3127", + } + +@misc{rfc3128, + author="I. Miller", + title="{Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)}", + howpublished="RFC 3128 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3128", + pages="1--5", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3128.txt", + key="RFC 3128", + abstract={This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the ``Tiny Fragment Attack'' described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. This memo provides information for the Internet community.}, + keywords="firewalls, internet", + doi="10.17487/RFC3128", + } + +@misc{rfc3129, + author="M. Thomas", + title="{Requirements for Kerberized Internet Negotiation of Keys}", + howpublished="RFC 3129 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3129", + pages="1--6", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3129.txt", + key="RFC 3129", + abstract={The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. This memo provides information for the Internet community.}, + keywords="KINK, cryptographic, security, authentication", + doi="10.17487/RFC3129", + } + +@misc{rfc3130, + author="E. Lewis", + title="{Notes from the State-Of-The-Technology: DNSSEC}", + howpublished="RFC 3130 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3130", + pages="1--10", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3130.txt", + key="RFC 3130", + abstract={This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. This memo provides information for the Internet community.}, + keywords="domain, name, system, security, extensions, report", + doi="10.17487/RFC3130", + } + +@misc{rfc3131, + author="S. Bradner and P. Calhoun and H. Cuschieri and S. Dennett and G. Flynn and M. Lipford and M. McPheters", + title="{3GPP2-IETF Standardization Collaboration}", + howpublished="RFC 3131 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3131", + pages="1--8", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3131.txt", + key="RFC 3131", + abstract={This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community.}, + keywords="internet, engineering, task, force, third generation, partnership project", + doi="10.17487/RFC3131", + } + +@misc{rfc3132, + author="J. Kempf", + title="{Dormant Mode Host Alerting (``IP Paging'') Problem Statement}", + howpublished="RFC 3132 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3132", + pages="1--14", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3132.txt", + key="RFC 3132", + abstract={This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. This memo provides information for the Internet community.}, + keywords="molulity, radio, link, internet, protocl", + doi="10.17487/RFC3132", + } + +@misc{rfc3133, + author="J. Dunn and C. Martin", + title="{Terminology for Frame Relay Benchmarking}", + howpublished="RFC 3133 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3133", + pages="1--24", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3133.txt", + key="RFC 3133", + abstract={This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. This memo provides information for the Internet community.}, + keywords="switching, devices, signaling", + doi="10.17487/RFC3133", + } + +@misc{rfc3134, + author="J. Dunn and C. Martin", + title="{Terminology for ATM ABR Benchmarking}", + howpublished="RFC 3134 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3134", + pages="1--16", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3134.txt", + key="RFC 3134", + abstract={This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR (Available Bit Rate). This memo provides information for the Internet community.}, + keywords="asynchronous, transfer, mode, available, bit rate", + doi="10.17487/RFC3134", + } + +@misc{rfc3135, + author="J. Border and M. Kojo and J. Griner and G. Montenegro and Z. Shelby", + title="{Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations}", + howpublished="RFC 3135 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3135", + pages="1--45", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3135.txt", + key="RFC 3135", + abstract={This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community.}, + keywords="PEP, PILC, TCP, transmission, control, protocol", + doi="10.17487/RFC3135", + } + +@misc{rfc3136, + author="L. {Slutsman (Ed.)} and I. Faynberg and H. Lu and M. Weissman", + title="{The SPIRITS Architecture}", + howpublished="RFC 3136 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3136", + pages="1--10", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3136.txt", + key="RFC 3136", + abstract={This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network)and necessitating the interactions between the PSTN and the Internet. This memo provides information for the Internet community.}, + keywords="PSTN, public, switched, telephone, network", + doi="10.17487/RFC3136", + } + +@misc{rfc3137, + author="A. Retana and L. Nguyen and R. White and A. Zinin and D. McPherson", + title="{OSPF Stub Router Advertisement}", + howpublished="RFC 3137 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3137", + pages="1--5", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6987", +url="https://www.rfc-editor.org/rfc/rfc3137.txt", + key="RFC 3137", + abstract={This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This memo provides information for the Internet community.}, + keywords="open, shortest, path, first", + doi="10.17487/RFC3137", + } + +@misc{rfc3138, + author="D. Meyer", + title="{Extended Assignments in 233/8}", + howpublished="RFC 3138 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3138", + pages="1--4", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5771", +url="https://www.rfc-editor.org/rfc/rfc3138.txt", + key="RFC 3138", + abstract={This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. This memo provides information for the Internet community.}, + keywords="internet, address, AS, autonomous, system, number", + doi="10.17487/RFC3138", + } + +@misc{rfc3139, + author="L. Sanchez and K. McCloghrie and J. Saperia", + title="{Requirements for Configuration Management of IP-based Networks}", + howpublished="RFC 3139 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3139", + pages="1--11", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3139.txt", + key="RFC 3139", + abstract={This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks. This memo provides information for the Internet community.}, + keywords="internet, protocol", + doi="10.17487/RFC3139", + } + +@misc{rfc3140, + author="D. Black and S. Brim and B. Carpenter and F. Le Faucheur", + title="{Per Hop Behavior Identification Codes}", + howpublished="RFC 3140 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3140", + pages="1--8", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3140.txt", + key="RFC 3140", + abstract={This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836. [STANDARDS-TRACK]}, + keywords="PHB, differentiated, services, codepoint, DSCP", + doi="10.17487/RFC3140", + } + +@misc{rfc3141, + author="T. Hiller and P. Walsh and X. Chen and M. Munson and G. Dommety and S. Sivalingham and B. Lim and P. McCann and H. Shiino and B. Hirschman and S. Manning and R. Hsu and H. Koo and M. Lipford and P. Calhoun and C. Lo and E. Jaques and E. Campbell and Y.Xu and S.Baba and T.Ayaki and T.Seki and A.Hameed", + title="{CDMA2000 Wireless Data Requirements for AAA}", + howpublished="RFC 3141 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3141", + pages="1--16", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3141.txt", + key="RFC 3141", + abstract={This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. This memo provides information for the Internet community.}, + keywords="authentication, authorization, accounting", + doi="10.17487/RFC3141", + } + +@misc{rfc3142, + author="J. Hagino and K. Yamamoto", + title="{An IPv6-to-IPv4 Transport Relay Translator}", + howpublished="RFC 3142 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3142", + pages="1--11", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3142.txt", + key="RFC 3142", + abstract={The document describes an IPv6-to-IPv4 transport relay translator (TRT). This memo provides information for the Internet community.}, + keywords="TRT, internet, protocol", + doi="10.17487/RFC3142", + } + +@misc{rfc3143, + author="I. Cooper and J. Dilley", + title="{Known HTTP Proxy/Caching Problems}", + howpublished="RFC 3143 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3143", + pages="1--32", + year=2001, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3143.txt", + key="RFC 3143", + abstract={This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. This memo provides information for the Internet community.}, + keywords="www, world wide web, hypertext transfer, protocol", + doi="10.17487/RFC3143", + } + +@misc{rfc3144, + author="D. Romascanu", + title="{Remote Monitoring MIB Extensions for Interface Parameters Monitoring}", + howpublished="RFC 3144 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3144", + pages="1--30", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3144.txt", + key="RFC 3144", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [STANDARDS-TRACK]}, + keywords="management, information, base", + doi="10.17487/RFC3144", + } + +@misc{rfc3145, + author="R. Verma and M. Verma and J. Carlson", + title="{L2TP Disconnect Cause Information}", + howpublished="RFC 3145 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3145", + pages="1--10", + year=2001, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3145.txt", + key="RFC 3145", + abstract={This document provides an extension to the Layer 2 Tunneling Protocol (``L2TP''), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS-TRACK]}, + keywords="layer2, tunneling, PPP, point-to-point, accounting, debugging", + doi="10.17487/RFC3145", + } + +@misc{rfc3146, + author="K. Fujisawa and A. Onoe", + title="{Transmission of IPv6 Packets over IEEE 1394 Networks}", + howpublished="RFC 3146 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3146", + pages="1--8", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc3146.txt", + key="RFC 3146", + abstract={This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS-TRACK]}, + keywords="link-local, addresses, statelessly, autoconfigured", + doi="10.17487/RFC3146", + } + +@misc{rfc3147, + author="P. Christian", + title="{Generic Routing Encapsulation over CLNS Networks}", + howpublished="RFC 3147 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3147", + pages="1--8", + year=2001, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3147.txt", + key="RFC 3147", + abstract={This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. This memo provides information for the Internet community.}, + keywords="connectionless, network, service, GRE, layer, protocol", + doi="10.17487/RFC3147", + } + +@misc{rfc3148, + author="M. Mathis and M. Allman", + title="{A Framework for Defining Empirical Bulk Transfer Capacity Metrics}", + howpublished="RFC 3148 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3148", + pages="1--16", + year=2001, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3148.txt", + key="RFC 3148", + abstract={This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity. This memo provides information for the Internet community.}, + keywords="BTC, transport, data", + doi="10.17487/RFC3148", + } + +@misc{rfc3149, + author="A. Srinath and G. Levendel and K. Fritz and R. Kalyanaram", + title="{MGCP Business Phone Packages}", + howpublished="RFC 3149 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3149", + pages="1--41", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3149.txt", + key="RFC 3149", + abstract={This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. This memo provides information for the Internet community.}, + keywords="media, gateway, control, packages", + doi="10.17487/RFC3149", + } + +@misc{rfc3150, + author="S. Dawkins and G. Montenegro and M. Kojo and V. Magret", + title="{End-to-end Performance Implications of Slow Links}", + howpublished="RFC 3150 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3150", + pages="1--17", + year=2001, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3150.txt", + key="RFC 3150", + abstract={This document makes performance-related recommendations for users of network paths that traverse ``very low bit-rate'' links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="PILC, data, applications, header, compression", + doi="10.17487/RFC3150", + } + +@misc{rfc3151, + author="N. Walsh and J. Cowan and P. Grosso", + title="{A URN Namespace for Public Identifiers}", + howpublished="RFC 3151 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3151", + pages="1--9", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3151.txt", + key="RFC 3151", + abstract={This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI (Uniform Resource Identifiers) syntax. This memo provides information for the Internet community.}, + keywords="uniform, resource, name, publicid", + doi="10.17487/RFC3151", + } + +@misc{rfc3152, + author="R. Bush", + title="{Delegation of IP6.ARPA}", + howpublished="RFC 3152 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3152", + pages="1--4", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3596", +url="https://www.rfc-editor.org/rfc/rfc3152.txt", + key="RFC 3152", + abstract={This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, protocol, domain, name, system, DNS, zone", + doi="10.17487/RFC3152", + } + +@misc{rfc3153, + author="R. Pazhyannur and I. Ali and C. Fox", + title="{PPP Multiplexing}", + howpublished="RFC 3153 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3153", + pages="1--9", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3153.txt", + key="RFC 3153", + abstract={This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links. [STANDARDS-TRACK]}, + keywords="point-to-point, protocol", + doi="10.17487/RFC3153", + } + +@misc{rfc3154, + author="J. Kempf and C. Castelluccia and P. Mutaf and N. Nakajima and Y. Ohba and R. Ramjee and Y. Saifullah and B. Sarikaya and X. Xu", + title="{Requirements and Functional Architecture for an IP Host Alerting Protocol}", + howpublished="RFC 3154 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3154", + pages="1--16", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3154.txt", + key="RFC 3154", + abstract={This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This memo provides information for the Internet community.}, + keywords="internet, protocol, paging, mobile, hosts", + doi="10.17487/RFC3154", + } + +@misc{rfc3155, + author="S. Dawkins and G. Montenegro and M. Kojo and V. Magret and N. Vaidya", + title="{End-to-end Performance Implications of Links with Errors}", + howpublished="RFC 3155 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3155", + pages="1--16", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3155.txt", + key="RFC 3155", + abstract={This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="TCP, transmission, control, protocol", + doi="10.17487/RFC3155", + } + +@misc{rfc3156, + author="M. Elkins and D. Del Torto and R. Levien and T. Roessler", + title="{MIME Security with OpenPGP}", + howpublished="RFC 3156 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3156", + pages="1--15", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3156.txt", + key="RFC 3156", + abstract={This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]}, + keywords="MIME-PGP, Authentication, Encryption", + doi="10.17487/RFC3156", + } + +@misc{rfc3157, + author="A. Arsenault and S. Farrell", + title="{Securely Available Credentials - Requirements}", + howpublished="RFC 3157 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3157", + pages="1--20", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3157.txt", + key="RFC 3157", + abstract={This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This memo provides information for the Internet community.}, + keywords="SACRED, trusted roots, private keys, PSE, personal security environment", + doi="10.17487/RFC3157", + } + +@misc{rfc3158, + author="C. Perkins and J. Rosenberg and H. Schulzrinne", + title="{RTP Testing Strategies}", + howpublished="RFC 3158 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3158", + pages="1--22", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3158.txt", + key="RFC 3158", + abstract={This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations. This memo provides information for the Internet community.}, + keywords="real-time, transport protocol", + doi="10.17487/RFC3158", + } + +@misc{rfc3159, + author="K. McCloghrie and M. Fine and J. Seligson and K. Chan and S. Hahn and R. Sahita and A. Smith and F. Reichmeyer", + title="{Structure of Policy Provisioning Information (SPPI)}", + howpublished="RFC 3159 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3159", + pages="1--40", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3159.txt", + key="RFC 3159", + abstract={This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS-TRACK]}, + keywords="PIB, base, SNMP, simple, network, management, information, SMI", + doi="10.17487/RFC3159", + } + +@misc{rfc3160, + author="S. Harris", + title="{The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force}", + howpublished="RFC 3160 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3160", + pages="1--38", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4677", +url="https://www.rfc-editor.org/rfc/rfc3160.txt", + key="RFC 3160", + abstract={This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. This memo provides information for the Internet community.}, + keywords="Internet, Engineering, Task, Force, Meeting", + doi="10.17487/RFC3160", + } + +@misc{rfc3161, + author="C. Adams and P. Cain and D. Pinkas and R. Zuccherato", + title="{Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)}", + howpublished="RFC 3161 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3161", + pages="1--26", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5816", +url="https://www.rfc-editor.org/rfc/rfc3161.txt", + key="RFC 3161", + abstract={This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]}, + keywords="TSA, authority, security, request, response", + doi="10.17487/RFC3161", + } + +@misc{rfc3162, + author="B. Aboba and G. Zorn and D. Mitton", + title="{RADIUS and IPv6}", + howpublished="RFC 3162 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3162", + pages="1--12", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8044", +url="https://www.rfc-editor.org/rfc/rfc3162.txt", + key="RFC 3162", + abstract={This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]}, + keywords="remote, authentication, dial in user, service, attributes", + doi="10.17487/RFC3162", + } + +@misc{rfc3163, + author="R. Zuccherato and M. Nystrom", + title="{ISO/IEC 9798-3 Authentication SASL Mechanism}", + howpublished="RFC 3163 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3163", + pages="1--17", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3163.txt", + key="RFC 3163", + abstract={This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community.}, + keywords="simple, authentication, security, layer", + doi="10.17487/RFC3163", + } + +@misc{rfc3164, + author="C. Lonvick", + title="{The BSD Syslog Protocol}", + howpublished="RFC 3164 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3164", + pages="1--29", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5424", +url="https://www.rfc-editor.org/rfc/rfc3164.txt", + key="RFC 3164", + abstract={This document describes the observed behavior of the syslog protocol. This memo provides information for the Internet community.}, + keywords="berkeley, software, distribution, transmission, messages", + doi="10.17487/RFC3164", + } + +@misc{rfc3165, + author="D. Levi and J. Schoenwaelder", + title="{Definitions of Managed Objects for the Delegation of Management Scripts}", + howpublished="RFC 3165 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3165", + pages="1--64", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3165.txt", + key="RFC 3165", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]}, + keywords="mib, information, base", + doi="10.17487/RFC3165", + } + +@misc{rfc3166, + author="D. Meyer and J. Scudder", + title="{Request to Move RFC 1403 to Historic Status}", + howpublished="RFC 3166 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3166", + pages="1--3", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3166.txt", + key="RFC 3166", + abstract={RFC 1403, ``BGP OSPF Interaction'', describes technology which is no longer used. This document requests that RFC 1403 be moved to Historic status. This memo provides information for the Internet community.}, + keywords="BGP-OSPF, Border gateway protocol, Open shortest path first routing", + doi="10.17487/RFC3166", + } + +@misc{rfc3167, + author="D. Meyer and J. Scudder", + title="{Request to Move RFC 1745 to Historic Status}", + howpublished="RFC 3167 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3167", + pages="1--3", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3167.txt", + key="RFC 3167", + abstract={RFC 1745, ``BGP4/IDRP for IP---OSPF Interaction'', describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status. This memo provides information for the Internet community.}, + keywords="BGP4/IDRP, Internet, Inter-Domain, Routing, Protocol, Border, Gateway, Open, Shortest, Path, First", + doi="10.17487/RFC3167", + } + +@misc{rfc3168, + author="K. Ramakrishnan and S. Floyd and D. Black", + title="{The Addition of Explicit Congestion Notification (ECN) to IP}", + howpublished="RFC 3168 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3168", + pages="1--63", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4301, 6040, 8311", +url="https://www.rfc-editor.org/rfc/rfc3168.txt", + key="RFC 3168", + abstract={This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]}, + keywords="internet, protocol, header", + doi="10.17487/RFC3168", + } + +@misc{rfc3169, + author="M. Beadles and D. Mitton", + title="{Criteria for Evaluating Network Access Server Protocols}", + howpublished="RFC 3169 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3169", + pages="1--17", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3169.txt", + key="RFC 3169", + abstract={This document defines requirements for protocols used by Network Access Servers (NAS). This memo provides information for the Internet community.}, + keywords="NAS, network, device, AAA, authentication, authorization, accounting", + doi="10.17487/RFC3169", + } + +@misc{rfc3170, + author="B. Quinn and K. Almeroth", + title="{IP Multicast Applications: Challenges and Solutions}", + howpublished="RFC 3170 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3170", + pages="1--28", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3170.txt", + key="RFC 3170", + abstract={This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. This memo provides information for the Internet community.}, + keywords="internet, protocol, unicast", + doi="10.17487/RFC3170", + } + +@misc{rfc3171, + author="Z. Albanna and K. Almeroth and D. Meyer and M. Schipper", + title="{IANA Guidelines for IPv4 Multicast Address Assignments}", + howpublished="RFC 3171 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3171", + pages="1--8", + year=2001, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5771", +url="https://www.rfc-editor.org/rfc/rfc3171.txt", + key="RFC 3171", + abstract={This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, assigned, numbers, authority, protocol, parameters", + doi="10.17487/RFC3171", + } + +@misc{rfc3172, + author="G. {Huston (Ed.)}", + title="{Management Guidelines \& Operational Requirements for the Address and Routing Parameter Area Domain (``arpa'')}", + howpublished="RFC 3172 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3172", + pages="1--8", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3172.txt", + key="RFC 3172", + abstract={This memo describes the management and operational requirements for the address and routing parameter area (``arpa'') domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="database, DNS, domain, name, system", + doi="10.17487/RFC3172", + } + +@misc{rfc3173, + author="A. Shacham and B. Monsour and R. Pereira and M. Thomas", + title="{IP Payload Compression Protocol (IPComp)}", + howpublished="RFC 3173 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3173", + pages="1--13", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3173.txt", + key="RFC 3173", + abstract={This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]}, + keywords="IPCOMP, internet, protocol, datagram, lossless", + doi="10.17487/RFC3173", + } + +@misc{rfc3174, + author="D. {Eastlake 3rd} and P. Jones", + title="{US Secure Hash Algorithm 1 (SHA1)}", + howpublished="RFC 3174 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3174", + pages="1--22", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4634, 6234", +url="https://www.rfc-editor.org/rfc/rfc3174.txt", + key="RFC 3174", + abstract={The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.}, + keywords="FIPS, federal, information, processing, standard", + doi="10.17487/RFC3174", + } + +@misc{rfc3175, + author="F. Baker and C. Iturralde and F. Le Faucheur and B. Davie", + title="{Aggregation of RSVP for IPv4 and IPv6 Reservations}", + howpublished="RFC 3175 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3175", + pages="1--36", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5350", +url="https://www.rfc-editor.org/rfc/rfc3175.txt", + key="RFC 3175", + abstract={This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, internet, ATM, asynchronous, transfer, mode", + doi="10.17487/RFC3175", + } + +@misc{rfc3176, + author="P. Phaal and S. Panchen and N. McKee", + title="{InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks}", + howpublished="RFC 3176 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3176", + pages="1--31", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3176.txt", + key="RFC 3176", + abstract={This memo defines InMon Corporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. This memo provides information for the Internet community.}, + keywords="agent, data, MIB, management, information, base", + doi="10.17487/RFC3176", + } + +@misc{rfc3177, + author="IAB and IESG", + title="{IAB/IESG Recommendations on IPv6 Address Allocations to Sites}", + howpublished="RFC 3177 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3177", + pages="1--10", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6177", +url="https://www.rfc-editor.org/rfc/rfc3177.txt", + key="RFC 3177", + abstract={This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.}, + keywords="internet, architecture, board, engineering, steering, group, protocol", + doi="10.17487/RFC3177", + } + +@misc{rfc3178, + author="J. Hagino and H. Snyder", + title="{IPv6 Multihoming Support at Site Exit Routers}", + howpublished="RFC 3178 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3178", + pages="1--12", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3178.txt", + key="RFC 3178", + abstract={The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. This memo provides information for the Internet community.}, + keywords="internet, protocol, ISP, Service, Provider, Routing", + doi="10.17487/RFC3178", + } + +@misc{rfc3179, + author="J. Schoenwaelder and J. Quittek", + title="{Script MIB Extensibility Protocol Version 1.1}", + howpublished="RFC 3179 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3179", + pages="1--25", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3179.txt", + key="RFC 3179", + abstract={The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. This memo defines an Experimental Protocol for the Internet community.}, + keywords="SMX, language, management, information, base", + doi="10.17487/RFC3179", + } + +@misc{rfc3180, + author="D. Meyer and P. Lothberg", + title="{GLOP Addressing in 233/8}", + howpublished="RFC 3180 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3180", + pages="1--5", + year=2001, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3180.txt", + key="RFC 3180", + abstract={This document defines the policy for the use of 233/8 for statically e assigned multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="static, multicast", + doi="10.17487/RFC3180", + } + +@misc{rfc3181, + author="S. Herzog", + title="{Signaled Preemption Priority Policy Element}", + howpublished="RFC 3181 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3181", + pages="1--12", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3181.txt", + key="RFC 3181", + abstract={This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). [STANDARDS-TRACK]}, + keywords="rsvp, resource, reservation, protocol, cops, common, open, service", + doi="10.17487/RFC3181", + } + +@misc{rfc3182, + author="S. Yadav and R. Yavatkar and R. Pabbati and P. Ford and T. Moore and S. Herzog and R. Hess", + title="{Identity Representation for RSVP}", + howpublished="RFC 3182 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3182", + pages="1--18", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3182.txt", + key="RFC 3182", + abstract={This document describes the representation of identity information in POLICY\_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol", + doi="10.17487/RFC3182", + } + +@misc{rfc3183, + author="T. Dean and W. Ottaway", + title="{Domain Security Services using S/MIME}", + howpublished="RFC 3183 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3183", + pages="1--24", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3183.txt", + key="RFC 3183", + abstract={This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community.}, + keywords="secure/multipurpose, internet, mail, extensions", + doi="10.17487/RFC3183", + } + +@misc{rfc3184, + author="S. Harris", + title="{IETF Guidelines for Conduct}", + howpublished="RFC 3184 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3184", + pages="1--4", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7154", +url="https://www.rfc-editor.org/rfc/rfc3184.txt", + key="RFC 3184", + abstract={This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, engineering, task, force", + doi="10.17487/RFC3184", + } + +@misc{rfc3185, + author="S. Farrell and S. Turner", + title="{Reuse of CMS Content Encryption Keys}", + howpublished="RFC 3185 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3185", + pages="1--10", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3185.txt", + key="RFC 3185", + abstract={This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. [STANDARDS-TRACK]}, + keywords="cryptographic, message, syntax, data, packets", + doi="10.17487/RFC3185", + } + +@misc{rfc3186, + author="S. Shimizu and T. Kawano and K. Murakami and E. Beier", + title="{MAPOS/PPP Tunneling mode}", + howpublished="RFC 3186 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3186", + pages="1--14", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3186.txt", + key="RFC 3186", + abstract={This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. This memo provides information for the Internet community.}, + keywords="multiple, access, protocol, over, SONET/SDH, point-to-point", + doi="10.17487/RFC3186", + } + +@misc{rfc3187, + author="J. Hakala and H. Walravens", + title="{Using International Standard Book Numbers as Uniform Resource Names}", + howpublished="RFC 3187 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3187", + pages="1--11", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8254", +url="https://www.rfc-editor.org/rfc/rfc3187.txt", + key="RFC 3187", + abstract={This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.}, + keywords="isbn, urn, bibliographic, identifiers", + doi="10.17487/RFC3187", + } + +@misc{rfc3188, + author="J. Hakala", + title="{Using National Bibliography Numbers as Uniform Resource Names}", + howpublished="RFC 3188 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3188", + pages="1--13", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3188.txt", + key="RFC 3188", + abstract={This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.}, + keywords="urn, nbn, national, libraries", + doi="10.17487/RFC3188", + } + +@misc{rfc3189, + author="K. Kobayashi and A. Ogawa and S. Casner and C. Bormann", + title="{RTP Payload Format for DV (IEC 61834) Video}", + howpublished="RFC 3189 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3189", + pages="1--13", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6469", +url="https://www.rfc-editor.org/rfc/rfc3189.txt", + key="RFC 3189", + abstract={This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as ``DV'' into a payload format for the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]}, + keywords="real-time, transport, protocol", + doi="10.17487/RFC3189", + } + +@misc{rfc3190, + author="K. Kobayashi and A. Ogawa and S. Casner and C. Bormann", + title="{RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio}", + howpublished="RFC 3190 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3190", + pages="1--17", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3190.txt", + key="RFC 3190", + abstract={This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear). [STANDARDS-TRACK]}, + keywords="real-time, transport, protocol, digital, audio, tape", + doi="10.17487/RFC3190", + } + +@misc{rfc3191, + author="C. Allocchio", + title="{Minimal GSTN address format in Internet Mail}", + howpublished="RFC 3191 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3191", + pages="1--13", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3191.txt", + key="RFC 3191", + abstract={This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses (commonly called ``telephone numbers'') in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. [STANDARDS-TRACK]}, + keywords="MIN-PSTN, global, switched, telephone, network, email", + doi="10.17487/RFC3191", + } + +@misc{rfc3192, + author="C. Allocchio", + title="{Minimal FAX address format in Internet Mail}", + howpublished="RFC 3192 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3192", + pages="1--11", + year=2001, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3192.txt", + key="RFC 3192", + abstract={This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses of facsimile devices in the local- part of Internet email addresses. [STANDARDS-TRACK]}, + keywords="MINFAX-IM, facsimile, GSTN, global, switched, telephone, network", + doi="10.17487/RFC3192", + } + +@misc{rfc3193, + author="B. Patel and B. Aboba and W. Dixon and G. Zorn and S. Booth", + title="{Securing L2TP using IPsec}", + howpublished="RFC 3193 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3193", + pages="1--28", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3193.txt", + key="RFC 3193", + abstract={This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. [STANDARDS-TRACK]}, + keywords="layer, two, tunneling, protocol, authentication", + doi="10.17487/RFC3193", + } + +@misc{rfc3194, + author="A. Durand and C. Huitema", + title="{The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio}", + howpublished="RFC 3194 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3194", + pages="1--7", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3194.txt", + key="RFC 3194", + abstract={This document provides an update on the ``H ratio'' defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. This memo provides information for the Internet community.}, + keywords="IPng, White, Paper", + doi="10.17487/RFC3194", + } + +@misc{rfc3195, + author="D. New and M. Rose", + title="{Reliable Delivery for syslog}", + howpublished="RFC 3195 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3195", + pages="1--36", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3195.txt", + key="RFC 3195", + abstract={The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. [STANDARDS-TRACK]}, + keywords="mappings, encryption, authentication, beep, blocks, extensible, exchange", + doi="10.17487/RFC3195", + } + +@misc{rfc3196, + author="T. Hastings and C. Manros and P. Zehler and C. Kugler and H. Holst", + title="{Internet Printing Protocol/1.1: Implementor's Guide}", + howpublished="RFC 3196 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3196", + pages="1--96", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3196.txt", + key="RFC 3196", + abstract={This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). This memo provides information for the Internet community.}, + keywords="IPP, client, object", + doi="10.17487/RFC3196", + } + +@misc{rfc3197, + author="R. Austein", + title="{Applicability Statement for DNS MIB Extensions}", + howpublished="RFC 3197 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3197", + pages="1--5", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3197.txt", + key="RFC 3197", + abstract={This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. This memo provides information for the Internet community.}, + keywords="DNS-R-MIB, Domain, Name, System, Management, Information, Base", + doi="10.17487/RFC3197", + } + +@misc{rfc3198, + author="A. Westerinen and J. Schnizlein and J. Strassner and M. Scherling and B. Quinn and S. Herzog and A. Huynh and M. Carlson and J. Perry and S. Waldbusser", + title="{Terminology for Policy-Based Management}", + howpublished="RFC 3198 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3198", + pages="1--21", + year=2001, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3198.txt", + key="RFC 3198", + abstract={This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community.}, + keywords="glossary, network, ISDs, internet, standard, documents", + doi="10.17487/RFC3198", + } + +@misc{rfc3199, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 3100-3199}", + howpublished="RFC 3199 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3199", + pages="1--24", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3199.txt", + key="RFC 3199", + doi="10.17487/RFC3199", + } + +@misc{rfc3201, + author="R. Steinberger and O. Nicklass", + title="{Definitions of Managed Objects for Circuit to Interface Translation}", + howpublished="RFC 3201 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3201", + pages="1--23", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3201.txt", + key="RFC 3201", + abstract={This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS-TRACK]}, + keywords="mib", + doi="10.17487/RFC3201", + } + +@misc{rfc3202, + author="R. Steinberger and O. Nicklass", + title="{Definitions of Managed Objects for Frame Relay Service Level Definitions}", + howpublished="RFC 3202 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3202", + pages="1--64", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3202.txt", + key="RFC 3202", + abstract={This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS-TRACK]}, + keywords="mib", + doi="10.17487/RFC3202", + } + +@misc{rfc3203, + author="Y. T'Joens and C. Hublet and P. De Schrijver", + title="{DHCP reconfigure extension}", + howpublished="RFC 3203 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3203", + pages="1--6", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6704", +url="https://www.rfc-editor.org/rfc/rfc3203.txt", + key="RFC 3203", + abstract={This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK]}, + keywords="dynamic, host, configuration, protocol, forcerenew", + doi="10.17487/RFC3203", + } + +@misc{rfc3204, + author="E. Zimmerer and J. Peterson and A. Vemuri and L. Ong and F. Audet and M. Watson and M. Zonoun", + title="{MIME media types for ISUP and QSIG Objects}", + howpublished="RFC 3204 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3204", + pages="1--10", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3459, 5621", +url="https://www.rfc-editor.org/rfc/rfc3204.txt", + key="RFC 3204", + abstract={This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS-TRACK]}, + keywords="multipart, internet, mail, extensions", + doi="10.17487/RFC3204", + } + +@misc{rfc3205, + author="K. Moore", + title="{On the use of HTTP as a Substrate}", + howpublished="RFC 3205 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3205", + pages="1--14", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3205.txt", + key="RFC 3205", + abstract={Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="hypertext, transfer, protocol, layering", + doi="10.17487/RFC3205", + } + +@misc{rfc3206, + author="R. Gellens", + title="{The SYS and AUTH POP Response Codes}", + howpublished="RFC 3206 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3206", + pages="1--6", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3206.txt", + key="RFC 3206", + abstract={This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS-TRACK]}, + keywords="security, authentication", + doi="10.17487/RFC3206", + } + +@misc{rfc3207, + author="P. Hoffman", + title="{SMTP Service Extension for Secure SMTP over Transport Layer Security}", + howpublished="RFC 3207 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3207", + pages="1--9", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7817", +url="https://www.rfc-editor.org/rfc/rfc3207.txt", + key="RFC 3207", + abstract={This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]}, + keywords="simple, mail, transfer, protocol, ssl, tls", + doi="10.17487/RFC3207", + } + +@misc{rfc3208, + author="T. Speakman and J. Crowcroft and J. Gemmell and D. Farinacci and S. Lin and D. Leshchiner and M. Luby and T. Montgomery and L. Rizzo and A. Tweedly and N. Bhaskar and R. Edmonstone and R. Sumanasekera and L. Vicisano", + title="{PGM Reliable Transport Protocol Specification}", + howpublished="RFC 3208 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3208", + pages="1--111", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3208.txt", + key="RFC 3208", + abstract={Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community.}, + keywords="pragmatic, general, multicast", + doi="10.17487/RFC3208", + } + +@misc{rfc3209, + author="D. Awduche and L. Berger and D. Gan and T. Li and V. Srinivasan and G. Swallow", + title="{RSVP-TE: Extensions to RSVP for LSP Tunnels}", + howpublished="RFC 3209 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3209", + pages="1--61", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3936, 4420, 4874, 5151, 5420, 5711, 6780, 6790, 7274", +url="https://www.rfc-editor.org/rfc/rfc3209.txt", + key="RFC 3209", + abstract={This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]}, + keywords="resource, reservation, protocol, label, switched, paths", + doi="10.17487/RFC3209", + } + +@misc{rfc3210, + author="D. Awduche and A. Hannan and X. Xiao", + title="{Applicability Statement for Extensions to RSVP for LSP-Tunnels}", + howpublished="RFC 3210 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3210", + pages="1--8", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3210.txt", + key="RFC 3210", + abstract={This memo discusses the applicability of ``Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels''. It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of ``Extensions to RSVP for LSP Tunnels'' onto the Internet standards track. This memo provides information for the Internet community.}, + keywords="resource, reservation, protocol, label, switched, paths", + doi="10.17487/RFC3210", + } + +@misc{rfc3211, + author="P. Gutmann", + title="{Password-based Encryption for CMS}", + howpublished="RFC 3211 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3211", + pages="1--17", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 3369, 3370", +url="https://www.rfc-editor.org/rfc/rfc3211.txt", + key="RFC 3211", + abstract={This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS-TRACK]}, + keywords="cryptographic, message, syntax, S/MIME, key wrap, derivation, passwordrecipientinfo, PWRI", + doi="10.17487/RFC3211", + } + +@misc{rfc3212, + author="B. {Jamoussi (Ed.)} and L. Andersson and R. Callon and R. Dantu and L. Wu and P. Doolan and T. Worster and N. Feldman and A. Fredette and M. Girish and E. Gray and J. Heinanen and T. Kilty and A. Malis", + title="{Constraint-Based LSP Setup using LDP}", + howpublished="RFC 3212 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3212", + pages="1--42", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3468, 7358", +url="https://www.rfc-editor.org/rfc/rfc3212.txt", + key="RFC 3212", + abstract={This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS-TRACK]}, + keywords="label, switching, protocol, distribution, CR", + doi="10.17487/RFC3212", + } + +@misc{rfc3213, + author="J. Ash and M. Girish and E. Gray and B. Jamoussi and G. Wright", + title="{Applicability Statement for CR-LDP}", + howpublished="RFC 3213 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3213", + pages="1--7", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3213.txt", + key="RFC 3213", + abstract={This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community.}, + keywords="constraint-based, label, distribution, protocol", + doi="10.17487/RFC3213", + } + +@misc{rfc3214, + author="J. Ash and Y. Lee and P. Ashwood-Smith and B. Jamoussi and D. Fedyk and D. Skalecki and L. Li", + title="{LSP Modification Using CR-LDP}", + howpublished="RFC 3214 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3214", + pages="1--11", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3214.txt", + key="RFC 3214", + abstract={This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS-TRACK]}, + keywords="label, switching, protocol, constraint-based, distribution", + doi="10.17487/RFC3214", + } + +@misc{rfc3215, + author="C. Boscher and P. Cheval and L. Wu and E. Gray", + title="{LDP State Machine}", + howpublished="RFC 3215 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3215", + pages="1--78", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3215.txt", + key="RFC 3215", + abstract={This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community.}, + keywords="label, distribution, protocol", + doi="10.17487/RFC3215", + } + +@misc{rfc3216, + author="C. Elliott and D. Harrington and J. Jason and J. Schoenwaelder and F. Strauss and W. Weiss", + title="{SMIng Objectives}", + howpublished="RFC 3216 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3216", + pages="1--33", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3216.txt", + key="RFC 3216", + abstract={This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community.}, + keywords="SNMP, simple, network, management, protocol, COPS-PR, common, open, policy, service, provisioning", + doi="10.17487/RFC3216", + } + +@misc{rfc3217, + author="R. Housley", + title="{Triple-DES and RC2 Key Wrapping}", + howpublished="RFC 3217 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3217", + pages="1--9", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3217.txt", + key="RFC 3217", + abstract={This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.}, + keywords="algorithm, data encryption standard", + doi="10.17487/RFC3217", + } + +@misc{rfc3218, + author="E. Rescorla", + title="{Preventing the Million Message Attack on Cryptographic Message Syntax}", + howpublished="RFC 3218 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3218", + pages="1--7", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3218.txt", + key="RFC 3218", + abstract={This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community.}, + keywords="cryptographic, syntax", + doi="10.17487/RFC3218", + } + +@misc{rfc3219, + author="J. Rosenberg and H. Salama and M. Squire", + title="{Telephony Routing over IP (TRIP)}", + howpublished="RFC 3219 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3219", + pages="1--79", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3219.txt", + key="RFC 3219", + abstract={This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS-TRACK]}, + keywords="inter-administrative, BGP, border, gateway, protocol", + doi="10.17487/RFC3219", + } + +@misc{rfc3220, + author="C. {Perkins (Ed.)}", + title="{IP Mobility Support for IPv4}", + howpublished="RFC 3220 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3220", + pages="1--98", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3344", +url="https://www.rfc-editor.org/rfc/rfc3220.txt", + key="RFC 3220", + abstract={This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]}, + keywords="MOBILEIPSUPIP, Internet, Protocol", + doi="10.17487/RFC3220", + } + +@misc{rfc3221, + author="G. Huston", + title="{Commentary on Inter-Domain Routing in the Internet}", + howpublished="RFC 3221 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3221", + pages="1--25", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3221.txt", + key="RFC 3221", + abstract={This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community.}, + keywords="BGP, border, gateway, protocol", + doi="10.17487/RFC3221", + } + +@misc{rfc3222, + author="G. Trotter", + title="{Terminology for Forwarding Information Base (FIB) based Router Performance}", + howpublished="RFC 3222 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3222", + pages="1--15", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3222.txt", + key="RFC 3222", + abstract={This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community.}, + keywords="internet, protocol, routing table, benchmark", + doi="10.17487/RFC3222", + } + +@misc{rfc3224, + author="E. Guttman", + title="{Vendor Extensions for Service Location Protocol, Version 2}", + howpublished="RFC 3224 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3224", + pages="1--10", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3224.txt", + key="RFC 3224", + abstract={This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, ``The Service Location Protocol.'' [STANDARDS-TRACK]}, + keywords="SLP, SVRLOC, opaque", + doi="10.17487/RFC3224", + } + +@misc{rfc3225, + author="D. Conrad", + title="{Indicating Resolver Support of DNSSEC}", + howpublished="RFC 3225 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3225", + pages="1--6", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4033, 4034, 4035", +url="https://www.rfc-editor.org/rfc/rfc3225.txt", + key="RFC 3225", + abstract={In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]}, + keywords="domain, name, system, security, extensions", + doi="10.17487/RFC3225", + } + +@misc{rfc3226, + author="O. Gudmundsson", + title="{DNSSEC and IPv6 A6 aware server/resolver message size requirements}", + howpublished="RFC 3226 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3226", + pages="1--6", + year=2001, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4033, 4034, 4035", +url="https://www.rfc-editor.org/rfc/rfc3226.txt", + key="RFC 3226", + abstract={This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS-TRACK]}, + keywords="domain, name, space, security, extensions, dns, endso", + doi="10.17487/RFC3226", + } + +@misc{rfc3227, + author="D. Brezinski and T. Killalea", + title="{Guidelines for Evidence Collection and Archiving}", + howpublished="RFC 3227 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3227", + pages="1--10", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3227.txt", + key="RFC 3227", + abstract={A ``security incident'' as defined in the ``Internet Security Glossary'', RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="security, incident", + doi="10.17487/RFC3227", + } + +@misc{rfc3228, + author="B. Fenner", + title="{IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)}", + howpublished="RFC 3228 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3228", + pages="1--4", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3228.txt", + key="RFC 3228", + abstract={This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="assigned, numbers, authority", + doi="10.17487/RFC3228", + } + +@misc{rfc3229, + author="J. Mogul and B. Krishnamurthy and F. Douglis and A. Feldmann and Y. Goland and A. van Hoff and D. Hellerstein", + title="{Delta encoding in HTTP}", + howpublished="RFC 3229 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3229", + pages="1--49", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3229.txt", + key="RFC 3229", + abstract={This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]}, + keywords="hyper, text, transfer, protocol", + doi="10.17487/RFC3229", + } + +@misc{rfc3230, + author="J. Mogul and A. Van Hoff", + title="{Instance Digests in HTTP}", + howpublished="RFC 3230 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3230", + pages="1--13", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3230.txt", + key="RFC 3230", + abstract={HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]}, + keywords="hyper, text, transfer, protocol", + doi="10.17487/RFC3230", + } + +@misc{rfc3231, + author="D. Levi and J. Schoenwaelder", + title="{Definitions of Managed Objects for Scheduling Management Operations}", + howpublished="RFC 3231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3231", + pages="1--29", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3231.txt", + key="RFC 3231", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS-TRACK]}, + keywords="mib, information, base", + doi="10.17487/RFC3231", + } + +@misc{rfc3232, + author="J. {Reynolds (Ed.)}", + title="{Assigned Numbers: RFC 1700 is Replaced by an On-line Database}", + howpublished="RFC 3232 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3232", + pages="1--3", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3232.txt", + key="RFC 3232", + abstract={This memo obsoletes RFC 1700 (STD 2) ``Assigned Numbers'', which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.}, + keywords="IANA, internet, assigned, numbers, authority, parameters", + doi="10.17487/RFC3232", + } + +@misc{rfc3233, + author="P. Hoffman and S. Bradner", + title="{Defining the IETF}", + howpublished="RFC 3233 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3233", + pages="1--4", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3233.txt", + key="RFC 3233", + abstract={This document gives a more concrete definition of ``the IETF'' as it understood today. Many RFCs refer to ``the IETF''. Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet, engineering, task, force", + doi="10.17487/RFC3233", + } + +@misc{rfc3234, + author="B. Carpenter and S. Brim", + title="{Middleboxes: Taxonomy and Issues}", + howpublished="RFC 3234 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3234", + pages="1--27", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3234.txt", + key="RFC 3234", + abstract={This document is intended as part of an IETF discussion about ``middleboxes'' - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.}, + keywords="internet, protocol, router, data, path, host", + doi="10.17487/RFC3234", + } + +@misc{rfc3235, + author="D. Senie", + title="{Network Address Translator (NAT)-Friendly Application Design Guidelines}", + howpublished="RFC 3235 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3235", + pages="1--13", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3235.txt", + key="RFC 3235", + abstract={This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community.}, + keywords="NAPT, ALG, firewall", + doi="10.17487/RFC3235", + } + +@misc{rfc3236, + author="M. Baker and P. Stark", + title="{The 'application/xhtml+xml' Media Type}", + howpublished="RFC 3236 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3236", + pages="1--8", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3236.txt", + key="RFC 3236", + abstract={This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.}, + keywords="mime, multipurpose, internet, mail, extensions", + doi="10.17487/RFC3236", + } + +@misc{rfc3237, + author="M. Tuexen and Q. Xie and R. Stewart and M. Shore and L. Ong and J. Loughney and M. Stillman", + title="{Requirements for Reliable Server Pooling}", + howpublished="RFC 3237 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3237", + pages="1--10", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3237.txt", + key="RFC 3237", + abstract={This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community.}, + keywords="rserpool, application", + doi="10.17487/RFC3237", + } + +@misc{rfc3238, + author="S. Floyd and L. Daigle", + title="{IAB Architectural and Policy Considerations for Open Pluggable Edge Services}", + howpublished="RFC 3238 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3238", + pages="1--17", + year=2002, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3238.txt", + key="RFC 3238", + abstract={This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community.}, + keywords="OPES, internet, architecture, board", + doi="10.17487/RFC3238", + } + +@misc{rfc3239, + author="C. Kugler and H. Lewis and T. Hastings", + title="{Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations}", + howpublished="RFC 3239 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3239", + pages="1--15", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3239.txt", + key="RFC 3239", + abstract={This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community.}, + keywords="object, device", + doi="10.17487/RFC3239", + } + +@misc{rfc3240, + author="D. Clunie and E. Cordonnier", + title="{Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration}", + howpublished="RFC 3240 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3240", + pages="1--6", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3240.txt", + key="RFC 3240", + abstract={This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in ``Digital Imaging and Communications in Medicine''. This memo provides information for the Internet community.}, + keywords="multipurpose, internet, mail, extensions", + doi="10.17487/RFC3240", + } + +@misc{rfc3241, + author="C. Bormann", + title="{Robust Header Compression (ROHC) over PPP}", + howpublished="RFC 3241 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3241", + pages="1--12", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4815", +url="https://www.rfc-editor.org/rfc/rfc3241.txt", + key="RFC 3241", + abstract={This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]}, + keywords="point-to-point protocol, datagram, packets", + doi="10.17487/RFC3241", + } + +@misc{rfc3242, + author="L-E. Jonsson and G. Pelletier", + title="{RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP}", + howpublished="RFC 3242 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3242", + pages="1--21", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4362", +url="https://www.rfc-editor.org/rfc/rfc3242.txt", + key="RFC 3242", + abstract={This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS-TRACK]}, + keywords="internet, protocol, user, datagram, real-time application, transport", + doi="10.17487/RFC3242", + } + +@misc{rfc3243, + author="L-E. Jonsson", + title="{RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression}", + howpublished="RFC 3243 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3243", + pages="1--6", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3243.txt", + key="RFC 3243", + abstract={This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.}, + keywords="internet, protocol, user, datagram, real-time application, transport, applications, LLA, link-layer assisted", + doi="10.17487/RFC3243", + } + +@misc{rfc3244, + author="M. Swift and J. Trostle and J. Brezak", + title="{Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols}", + howpublished="RFC 3244 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3244", + pages="1--7", + year=2002, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3244.txt", + key="RFC 3244", + abstract={This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB\_PRIV message that contains the new password for the user. This memo provides information for the Internet community.}, + keywords="security, message, codes", + doi="10.17487/RFC3244", + } + +@misc{rfc3245, + author="J. {Klensin (Ed.)} and IAB", + title="{The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)}", + howpublished="RFC 3245 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3245", + pages="1--10", + year=2002, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3245.txt", + key="RFC 3245", + abstract={RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of ``country code''-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.}, + keywords="IAB, ARPA", + doi="10.17487/RFC3245", + } + +@misc{rfc3246, + author="B. Davie and A. Charny and J.C.R. Bennet and K. Benson and J.Y. Le Boudec and W. Courtney and S. Davari and V. Firoiu and D. Stiliadis", + title="{An Expedited Forwarding PHB (Per-Hop Behavior)}", + howpublished="RFC 3246 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3246", + pages="1--16", + year=2002, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3246.txt", + key="RFC 3246", + abstract={This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]}, + keywords="per-hop behavior, expedited forwarding, differentiated services, delay, jitter", + doi="10.17487/RFC3246", + } + +@misc{rfc3247, + author="A. Charny and J. Bennet and K. Benson and J. Boudec and A. Chiu and W. Courtney and S. Davari and V. Firoiu and C. Kalmanek and K. Ramakrishnan", + title="{Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)}", + howpublished="RFC 3247 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3247", + pages="1--24", + year=2002, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3247.txt", + key="RFC 3247", + abstract={This document was written during the process of clarification of RFC2598 ``An Expedited Forwarding PHB'' that led to the publication of revised specification of EF ``An Expedited Forwarding PHB''. Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community.}, + keywords="differentiated services, fifo, fair queuing, delay, jitter", + doi="10.17487/RFC3247", + } + +@misc{rfc3248, + author="G. Armitage and B. Carpenter and A. Casati and J. Crowcroft and J. Halpern and B. Kumar and J. Schnizlein", + title="{A Delay Bound alternative revision of RFC 2598}", + howpublished="RFC 3248 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3248", + pages="1--11", + year=2002, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3248.txt", + key="RFC 3248", + abstract={For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community.}, + keywords="per hop behavior, phb, expedited forwarding, ef, db", + doi="10.17487/RFC3248", + } + +@misc{rfc3249, + author="V. Cancio and M. Moldovan and H. Tamura and D. Wing", + title="{Implementers Guide for Facsimile Using Internet Mail}", + howpublished="RFC 3249 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3249", + pages="1--21", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3249.txt", + key="RFC 3249", + abstract={This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community.}, + keywords="fax, tiff, tiff-fx, ifax, e-mail, email, esmtp, dsn, mdn", + doi="10.17487/RFC3249", + } + +@misc{rfc3250, + author="L. McIntyre and G. Parsons and J. Rafferty", + title="{Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration}", + howpublished="RFC 3250 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3250", + pages="1--7", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3950", +url="https://www.rfc-editor.org/rfc/rfc3250.txt", + key="RFC 3250", + abstract={This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]}, + keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions", + doi="10.17487/RFC3250", + } + +@misc{rfc3251, + author="B. Rajagopalan", + title="{Electricity over IP}", + howpublished="RFC 3251 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3251", + pages="1--9", + year=2002, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3251.txt", + key="RFC 3251", + abstract={Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, ``What next?''. This document answers that question. This memo provides information for the Internet community.}, + keywords="Internet Protocol", + doi="10.17487/RFC3251", + } + +@misc{rfc3252, + author="H. Kennedy", + title="{Binary Lexical Octet Ad-hoc Transport}", + howpublished="RFC 3252 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3252", + pages="1--16", + year=2002, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3252.txt", + key="RFC 3252", + abstract={This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.}, + keywords="bloat", + doi="10.17487/RFC3252", + } + +@misc{rfc3253, + author="G. Clemm and J. Amsden and T. Ellison and C. Kaler and J. Whitehead", + title="{Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)}", + howpublished="RFC 3253 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3253", + pages="1--118", + year=2002, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3253.txt", + key="RFC 3253", + abstract={This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS-TRACK]}, + keywords="hypertext, transfer, protocol, clients, label, configuration, management", + doi="10.17487/RFC3253", + } + +@misc{rfc3254, + author="H. Alvestrand", + title="{Definitions for talking about directories}", + howpublished="RFC 3254 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3254", + pages="1--11", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3254.txt", + key="RFC 3254", + abstract={When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, ``directories''. This memo provides information for the Internet community.}, + keywords="domain, name, system, lightweight, access, protocol", + doi="10.17487/RFC3254", + } + +@misc{rfc3255, + author="N. Jones and C. Murton", + 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}", + howpublished="RFC 3255 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3255", + pages="1--8", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3255.txt", + key="RFC 3255", + abstract={This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3255", + } + +@misc{rfc3256, + author="D. Jones and R. Woundy", + title="{The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option}", + howpublished="RFC 3256 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3256", + pages="1--5", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3256.txt", + key="RFC 3256", + abstract={This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3256", + } + +@misc{rfc3257, + author="L. Coene", + title="{Stream Control Transmission Protocol Applicability Statement}", + howpublished="RFC 3257 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3257", + pages="1--13", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3257.txt", + key="RFC 3257", + abstract={This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) \& 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.}, + keywords="sctp, udp, tcp, rtp, transport security, transport, nat, multihoming", + doi="10.17487/RFC3257", + } + +@misc{rfc3258, + author="T. Hardie", + title="{Distributing Authoritative Name Servers via Shared Unicast Addresses}", + howpublished="RFC 3258 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3258", + pages="1--11", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3258.txt", + key="RFC 3258", + abstract={This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community.}, + keywords="dns, network, topology, latency", + doi="10.17487/RFC3258", + } + +@misc{rfc3259, + author="J. Ott and C. Perkins and D. Kutscher", + title="{A Message Bus for Local Coordination}", + howpublished="RFC 3259 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3259", + pages="1--39", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3259.txt", + key="RFC 3259", + abstract={The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community.}, + keywords="mbus, message, ip, multicast, addressing, transport, syntax", + doi="10.17487/RFC3259", + } + +@misc{rfc3260, + author="D. Grossman", + title="{New Terminology and Clarifications for Diffserv}", + howpublished="RFC 3260 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3260", + pages="1--10", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3260.txt", + key="RFC 3260", + abstract={This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.}, + keywords="DIFFSRV, scalability, IP, internet, protocol", + doi="10.17487/RFC3260", + } + +@misc{rfc3261, + author="J. Rosenberg and H. Schulzrinne and G. Camarillo and A. Johnston and J. Peterson and R. Sparks and M. Handley and E. Schooler", + title="{SIP: Session Initiation Protocol}", + howpublished="RFC 3261 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3261", + pages="1--269", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3265, 3853, 4320, 4916, 5393, 5621, 5626, 5630, 5922, 5954, 6026, 6141, 6665, 6878, 7462, 7463, 8217", +url="https://www.rfc-editor.org/rfc/rfc3261.txt", + key="RFC 3261", + abstract={This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC3261", + } + +@misc{rfc3262, + author="J. Rosenberg and H. Schulzrinne", + title="{Reliability of Provisional Responses in Session Initiation Protocol (SIP)}", + howpublished="RFC 3262 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3262", + pages="1--14", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3262.txt", + key="RFC 3262", + abstract={This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC3262", + } + +@misc{rfc3263, + author="J. Rosenberg and H. Schulzrinne", + title="{Session Initiation Protocol (SIP): Locating SIP Servers}", + howpublished="RFC 3263 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3263", + pages="1--17", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7984", +url="https://www.rfc-editor.org/rfc/rfc3263.txt", + key="RFC 3263", + abstract={The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC3263", + } + +@misc{rfc3264, + author="J. Rosenberg and H. Schulzrinne", + title="{An Offer/Answer Model with Session Description Protocol (SDP)}", + howpublished="RFC 3264 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3264", + pages="1--25", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6157", +url="https://www.rfc-editor.org/rfc/rfc3264.txt", + key="RFC 3264", + abstract={This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC3264", + } + +@misc{rfc3265, + author="A. B. Roach", + title="{Session Initiation Protocol (SIP)-Specific Event Notification}", + howpublished="RFC 3265 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3265", + pages="1--38", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6665, updated by RFCs 5367, 5727, 6446", +url="https://www.rfc-editor.org/rfc/rfc3265.txt", + key="RFC 3265", + abstract={This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS-TRACK]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC3265", + } + +@misc{rfc3266, + author="S. Olson and G. Camarillo and A. B. Roach", + title="{Support for IPv6 in Session Description Protocol (SDP)}", + howpublished="RFC 3266 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3266", + pages="1--5", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4566", +url="https://www.rfc-editor.org/rfc/rfc3266.txt", + key="RFC 3266", + abstract={This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS-TRACK]}, + keywords="internet addresses syntax", + doi="10.17487/RFC3266", + } + +@misc{rfc3267, + author="J. Sjoberg and M. Westerlund and A. Lakaniemi and Q. Xie", + 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}", + howpublished="RFC 3267 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3267", + pages="1--49", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4867", +url="https://www.rfc-editor.org/rfc/rfc3267.txt", + key="RFC 3267", + abstract={This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS-TRACK]}, + keywords="interoperate, applications", + doi="10.17487/RFC3267", + } + +@misc{rfc3268, + author="P. Chown", + title="{Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)}", + howpublished="RFC 3268 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3268", + pages="1--7", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5246", +url="https://www.rfc-editor.org/rfc/rfc3268.txt", + key="RFC 3268", + abstract={This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS-TRACK]}, + keywords="idea, international data algorithm, symmetric", + doi="10.17487/RFC3268", + } + +@misc{rfc3269, + author="R. Kermode and L. Vicisano", + title="{Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents}", + howpublished="RFC 3269 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3269", + pages="1--12", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3269.txt", + key="RFC 3269", + abstract={This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.}, + keywords="definitions, operation", + doi="10.17487/RFC3269", + } + +@misc{rfc3270, + author="F. Le Faucheur and L. Wu and B. Davie and S. Davari and P. Vaananen and R. Krishnan and P. Cheval and J. Heinanen", + title="{Multi-Protocol Label Switching (MPLS) Support of Differentiated Services}", + howpublished="RFC 3270 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3270", + pages="1--64", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc3270.txt", + key="RFC 3270", + abstract={This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]}, + keywords="diff-serv, ba, behaviour aggregate, lsp, label switched paths", + doi="10.17487/RFC3270", + } + +@misc{rfc3271, + author="V. Cerf", + title="{The Internet is for Everyone}", + howpublished="RFC 3271 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3271", + pages="1--6", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3271.txt", + key="RFC 3271", + abstract={This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community.}, + keywords="isoc, internet society, policy issues, social impact, economic impact, international policy, use and abuse of the internet", + doi="10.17487/RFC3271", + } + +@misc{rfc3272, + author="D. Awduche and A. Chiu and A. Elwalid and I. Widjaja and X. Xiao", + title="{Overview and Principles of Internet Traffic Engineering}", + howpublished="RFC 3272 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3272", + pages="1--71", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc3272.txt", + key="RFC 3272", + abstract={This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community.}, + keywords="te, ip, networks", + doi="10.17487/RFC3272", + } + +@misc{rfc3273, + author="S. Waldbusser", + title="{Remote Network Monitoring Management Information Base for High Capacity Networks}", + howpublished="RFC 3273 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3273", + pages="1--77", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4502", +url="https://www.rfc-editor.org/rfc/rfc3273.txt", + key="RFC 3273", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]}, + keywords="rmon, mib, high speed networks", + doi="10.17487/RFC3273", + } + +@misc{rfc3274, + author="P. Gutmann", + title="{Compressed Data Content Type for Cryptographic Message Syntax (CMS)}", + howpublished="RFC 3274 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3274", + pages="1--6", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3274.txt", + key="RFC 3274", + abstract={This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK]}, + keywords="content info type", + doi="10.17487/RFC3274", + } + +@misc{rfc3275, + author="D. {Eastlake 3rd} and J. Reagle and D. Solo", + title="{(Extensible Markup Language) XML-Signature Syntax and Processing}", + howpublished="RFC 3275 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3275", + pages="1--73", + year=2002, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3275.txt", + key="RFC 3275", + abstract={This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]}, + keywords="extensible, markup, language", + doi="10.17487/RFC3275", + } + +@misc{rfc3276, + author="B. Ray and R. Abbi", + title="{Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing}", + howpublished="RFC 3276 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3276", + pages="1--66", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4319", +url="https://www.rfc-editor.org/rfc/rfc3276.txt", + key="RFC 3276", + abstract={This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS-TRACK]}, + keywords="mib, interfaces", + doi="10.17487/RFC3276", + } + +@misc{rfc3277, + author="D. McPherson", + title="{Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance}", + howpublished="RFC 3277 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3277", + pages="1--6", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3277.txt", + key="RFC 3277", + abstract={This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community.}, + keywords="router", + doi="10.17487/RFC3277", + } + +@misc{rfc3278, + author="S. Blake-Wilson and D. Brown and P. Lambert", + title="{Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 3278 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3278", + pages="1--16", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5753", +url="https://www.rfc-editor.org/rfc/rfc3278.txt", + key="RFC 3278", + abstract={This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community.}, + keywords="public key, digital signatures, authentication", + doi="10.17487/RFC3278", + } + +@misc{rfc3279, + author="L. Bassham and W. Polk and R. Housley", + title="{Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}", + howpublished="RFC 3279 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3279", + pages="1--27", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4055, 4491, 5480, 5758", +url="https://www.rfc-editor.org/rfc/rfc3279.txt", + key="RFC 3279", + abstract={This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]}, + keywords="ASN.1", + doi="10.17487/RFC3279", + } + +@misc{rfc3280, + author="R. Housley and W. Polk and W. Ford and D. Solo", + title="{Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}", + howpublished="RFC 3280 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3280", + pages="1--129", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5280, updated by RFCs 4325, 4630", +url="https://www.rfc-editor.org/rfc/rfc3280.txt", + key="RFC 3280", + abstract={This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3280", + } + +@misc{rfc3281, + author="S. Farrell and R. Housley", + title="{An Internet Attribute Certificate Profile for Authorization}", + howpublished="RFC 3281 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3281", + pages="1--40", + year=2002, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5755", +url="https://www.rfc-editor.org/rfc/rfc3281.txt", + key="RFC 3281", + abstract={This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]}, + keywords="electronic mail, email, ipsec, www security", + doi="10.17487/RFC3281", + } + +@misc{rfc3282, + author="H. Alvestrand", + title="{Content Language Headers}", + howpublished="RFC 3282 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3282", + pages="1--8", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3282.txt", + key="RFC 3282", + abstract={This document defines a ``Content-language:'' header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an ``Accept-Language:'' header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3282", + } + +@misc{rfc3283, + author="B. Mahoney and G. Babics and A. Taler", + title="{Guide to Internet Calendaring}", + howpublished="RFC 3283 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3283", + pages="1--16", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3283.txt", + key="RFC 3283", + abstract={This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is ``Calendar Access Protocol'' (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.}, + keywords="scheduling systems, cap, calendar access protocool, itip, imip", + doi="10.17487/RFC3283", + } + +@misc{rfc3284, + author="D. Korn and J. MacDonald and J. Mogul and K. Vo", + title="{The VCDIFF Generic Differencing and Compression Data Format}", + howpublished="RFC 3284 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3284", + pages="1--29", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3284.txt", + key="RFC 3284", + abstract={This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]}, + keywords="transport, portable, at\&t, encoding", + doi="10.17487/RFC3284", + } + +@misc{rfc3285, + author="M. Gahrns and T. Hain", + title="{Using Microsoft Word to create Internet Drafts and RFCs}", + howpublished="RFC 3285 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3285", + pages="1--19", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5385", +url="https://www.rfc-editor.org/rfc/rfc3285.txt", + key="RFC 3285", + abstract={This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community.}, + doi="10.17487/RFC3285", + } + +@misc{rfc3286, + author="L. Ong and J. Yoakum", + title="{An Introduction to the Stream Control Transmission Protocol (SCTP)}", + howpublished="RFC 3286 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3286", + pages="1--10", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3286.txt", + key="RFC 3286", + abstract={This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community.}, + keywords="transport, layer, telephony, signaling", + doi="10.17487/RFC3286", + } + +@misc{rfc3287, + author="A. Bierman", + title="{Remote Monitoring MIB Extensions for Differentiated Services}", + howpublished="RFC 3287 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3287", + pages="1--120", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3287.txt", + key="RFC 3287", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS-TRACK]}, + keywords="rmon, management information base, diffserv", + doi="10.17487/RFC3287", + } + +@misc{rfc3288, + author="E. O'Tuathail and M. Rose", + title="{Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)}", + howpublished="RFC 3288 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3288", + pages="1--20", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4227", +url="https://www.rfc-editor.org/rfc/rfc3288.txt", + key="RFC 3288", + abstract={This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS-TRACK]}, + keywords="binding, markup language, xml", + doi="10.17487/RFC3288", + } + +@misc{rfc3289, + author="F. Baker and K. Chan and A. Smith", + title="{Management Information Base for the Differentiated Services Architecture}", + howpublished="RFC 3289 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3289", + pages="1--116", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3289.txt", + key="RFC 3289", + abstract={This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS-TRACK]}, + keywords="mib, diffserv, router, architecture", + doi="10.17487/RFC3289", + } + +@misc{rfc3290, + author="Y. Bernet and S. Blake and D. Grossman and A. Smith", + title="{An Informal Management Model for Diffserv Routers}", + howpublished="RFC 3290 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3290", + pages="1--56", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3290.txt", + key="RFC 3290", + abstract={This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.}, + keywords="differentiated services", + doi="10.17487/RFC3290", + } + +@misc{rfc3291, + author="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder", + title="{Textual Conventions for Internet Network Addresses}", + howpublished="RFC 3291 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3291", + pages="1--20", + year=2002, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4001", +url="https://www.rfc-editor.org/rfc/rfc3291.txt", + key="RFC 3291", + abstract={This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]}, + keywords="tc, mib, layer, management, information, base", + doi="10.17487/RFC3291", + } + +@misc{rfc3292, + author="A. Doria and F. Hellstrand and K. Sundell and T. Worster", + title="{General Switch Management Protocol (GSMP) V3}", + howpublished="RFC 3292 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3292", + pages="1--137", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3292.txt", + key="RFC 3292", + abstract={This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS-TRACK]}, + keywords="switch, label, unicast, multicast, qos, quality of service", + doi="10.17487/RFC3292", + } + +@misc{rfc3293, + author="T. Worster and A. Doria and J. Buerkle", + title="{General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)}", + howpublished="RFC 3293 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3293", + pages="1--9", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3293.txt", + key="RFC 3293", + abstract={This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3293", + } + +@misc{rfc3294, + author="A. Doria and K. Sundell", + title="{General Switch Management Protocol (GSMP) Applicability}", + howpublished="RFC 3294 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3294", + pages="1--9", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3294.txt", + key="RFC 3294", + abstract={This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community.}, + keywords="internet", + doi="10.17487/RFC3294", + } + +@misc{rfc3295, + author="H. Sjostrand and J. Buerkle and B. Srinivasan", + title="{Definitions of Managed Objects for the General Switch Management Protocol (GSMP)}", + howpublished="RFC 3295 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3295", + pages="1--47", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3295.txt", + key="RFC 3295", + abstract={This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS-TRACK]}, + keywords="mib, management information base, controller, gsmp-mib", + doi="10.17487/RFC3295", + } + +@misc{rfc3296, + author="K. Zeilenga", + title="{Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories}", + howpublished="RFC 3296 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3296", + pages="1--14", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3296.txt", + key="RFC 3296", + abstract={This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS-TRACK]}, + keywords="schema, elements, description, formats", + doi="10.17487/RFC3296", + } + +@misc{rfc3297, + author="G. Klyne and R. Iwazaki and D. Crocker", + title="{Content Negotiation for Messaging Services based on Email}", + howpublished="RFC 3297 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3297", + pages="1--46", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3297.txt", + key="RFC 3297", + abstract={This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK]}, + keywords="facsimile", + doi="10.17487/RFC3297", + } + +@misc{rfc3298, + author="I. Faynberg and J. Gato and H. Lu and L. Slutsman", + title="{Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements}", + howpublished="RFC 3298 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3298", + pages="1--17", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3298.txt", + key="RFC 3298", + abstract={This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for ``Service in the PSTN/IN Requesting InTernet Service''.) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community.}, + keywords="support", + doi="10.17487/RFC3298", + } + +@misc{rfc3299, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 3200-3299}", + howpublished="RFC 3299 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3299", + pages="1--30", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3299.txt", + key="RFC 3299", + doi="10.17487/RFC3299", + } + +@misc{rfc3300, + author="J. Reynolds and R. Braden and S. Ginoza and A. De La Cruz", + title="{Internet Official Protocol Standards}", + howpublished="RFC 3300 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3300", + pages="1--49", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3600", +url="https://www.rfc-editor.org/rfc/rfc3300.txt", + key="RFC 3300", + doi="10.17487/RFC3300", + } + +@misc{rfc3301, + author="Y. T'Joens and P. Crivellari and B. Sales", + title="{Layer Two Tunnelling Protocol (L2TP): ATM access network extensions}", + howpublished="RFC 3301 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3301", + pages="1--19", + year=2002, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3301.txt", + key="RFC 3301", + keywords="", + doi="10.17487/RFC3301", + } + +@misc{rfc3302, + author="G. Parsons and J. Rafferty", + title="{Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration}", + howpublished="RFC 3302 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3302", + pages="1--8", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3302.txt", + key="RFC 3302", + keywords="TIFF, Multipurpose, Internet, Mail, extensions", + doi="10.17487/RFC3302", + } + +@misc{rfc3303, + author="P. Srisuresh and J. Kuthan and J. Rosenberg and A. Molitor and A. Rayhan", + title="{Middlebox communication architecture and framework}", + howpublished="RFC 3303 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3303", + pages="1--34", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3303.txt", + key="RFC 3303", + keywords="midcom", + doi="10.17487/RFC3303", + } + +@misc{rfc3304, + author="R. P. Swale and P. A. Mart and P. Sijben and S. Brim and M. Shore", + title="{Middlebox Communications (midcom) Protocol Requirements}", + howpublished="RFC 3304 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3304", + pages="1--9", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3304.txt", + key="RFC 3304", + keywords="nat, network address protocol, firewall middleboxes", + doi="10.17487/RFC3304", + } + +@misc{rfc3305, + author="M. {Mealling (Ed.)} and R. {Denenberg (Ed.)}", + title="{Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations}", + howpublished="RFC 3305 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3305", + pages="1--11", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3305.txt", + key="RFC 3305", + keywords="internet engineering task force", + doi="10.17487/RFC3305", + } + +@misc{rfc3306, + author="B. Haberman and D. Thaler", + title="{Unicast-Prefix-based IPv6 Multicast Addresses}", + howpublished="RFC 3306 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3306", + pages="1--7", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3956, 4489, 7371", +url="https://www.rfc-editor.org/rfc/rfc3306.txt", + key="RFC 3306", + keywords="internet protocol", + doi="10.17487/RFC3306", + } + +@misc{rfc3307, + author="B. Haberman", + title="{Allocation Guidelines for IPv6 Multicast Addresses}", + howpublished="RFC 3307 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3307", + pages="1--8", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3307.txt", + key="RFC 3307", + keywords="internet protocol", + doi="10.17487/RFC3307", + } + +@misc{rfc3308, + author="P. Calhoun and W. Luo and D. McPherson and K. Peirce", + title="{Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension}", + howpublished="RFC 3308 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3308", + pages="1--10", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3308.txt", + key="RFC 3308", + keywords="per hop behavior, phb, diffserv", + doi="10.17487/RFC3308", + } + +@misc{rfc3309, + author="J. Stone and R. Stewart and D. Otis", + title="{Stream Control Transmission Protocol (SCTP) Checksum Change}", + howpublished="RFC 3309 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3309", + pages="1--17", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4960", +url="https://www.rfc-editor.org/rfc/rfc3309.txt", + key="RFC 3309", + keywords="adler-32, checksum, error detection", + doi="10.17487/RFC3309", + } + +@misc{rfc3310, + author="A. Niemi and J. Arkko and V. Torvinen", + title="{Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)}", + howpublished="RFC 3310 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3310", + pages="1--18", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3310.txt", + key="RFC 3310", + keywords="one-time password generation mechanism, umts, universal mobile telecommunications system", + doi="10.17487/RFC3310", + } + +@misc{rfc3311, + author="J. Rosenberg", + title="{The Session Initiation Protocol (SIP) UPDATE Method}", + howpublished="RFC 3311 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3311", + pages="1--13", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3311.txt", + key="RFC 3311", + keywords="parameters, media streams", + doi="10.17487/RFC3311", + } + +@misc{rfc3312, + author="G. {Camarillo (Ed.)} and W. {Marshall (Ed.)} and J. Rosenberg", + title="{Integration of Resource Management and Session Initiation Protocol (SIP)}", + howpublished="RFC 3312 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3312", + pages="1--30", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4032, 5027", +url="https://www.rfc-editor.org/rfc/rfc3312.txt", + key="RFC 3312", + keywords="qos, quality of service, precondition", + doi="10.17487/RFC3312", + } + +@misc{rfc3313, + author="W. {Marshall (Ed.)}", + title="{Private Session Initiation Protocol (SIP) Extensions for Media Authorization}", + howpublished="RFC 3313 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3313", + pages="1--16", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3313.txt", + key="RFC 3313", + keywords="qos, quality of service", + doi="10.17487/RFC3313", + } + +@misc{rfc3314, + author="M. {Wasserman (Ed.)}", + title="{Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards}", + howpublished="RFC 3314 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3314", + pages="1--23", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3314.txt", + key="RFC 3314", + keywords="internet protocol", + doi="10.17487/RFC3314", + } + +@misc{rfc3315, + author="R. {Droms (Ed.)} and J. Bound and B. Volz and T. Lemon and C. Perkins and M. Carney", + title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}", + howpublished="RFC 3315 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3315", + pages="1--101", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4361, 5494, 6221, 6422, 6644, 7083, 7227, 7283, 7550", +url="https://www.rfc-editor.org/rfc/rfc3315.txt", + key="RFC 3315", + keywords="internet protocol, parameters, addresses", + doi="10.17487/RFC3315", + } + +@misc{rfc3316, + author="J. Arkko and G. Kuijpers and H. Soliman and J. Loughney and J. Wiljakka", + title="{Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts}", + howpublished="RFC 3316 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3316", + pages="1--22", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7066", +url="https://www.rfc-editor.org/rfc/rfc3316.txt", + key="RFC 3316", + keywords="links, bandwidth", + doi="10.17487/RFC3316", + } + +@misc{rfc3317, + author="K. Chan and R. Sahita and S. Hahn and K. McCloghrie", + title="{Differentiated Services Quality of Service Policy Information Base}", + howpublished="RFC 3317 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3317", + pages="1--96", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3317.txt", + key="RFC 3317", + keywords="pib, differentiated services architecture", + doi="10.17487/RFC3317", + } + +@misc{rfc3318, + author="R. {Sahita (Ed.)} and S. Hahn and K. Chan and K. McCloghrie", + title="{Framework Policy Information Base}", + howpublished="RFC 3318 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3318", + pages="1--70", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3318.txt", + key="RFC 3318", + abstract={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. 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). 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. 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.}, + doi="10.17487/RFC3318", + } + +@misc{rfc3319, + author="H. Schulzrinne and B. Volz", + title="{Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers}", + howpublished="RFC 3319 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3319", + pages="1--7", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3319.txt", + key="RFC 3319", + keywords="outbound proxy servers", + doi="10.17487/RFC3319", + } + +@misc{rfc3320, + author="R. Price and C. Bormann and J. Christoffersson and H. Hannu and Z. Liu and J. Rosenberg", + title="{Signaling Compression (SigComp)}", + howpublished="RFC 3320 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3320", + pages="1--62", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4896", +url="https://www.rfc-editor.org/rfc/rfc3320.txt", + key="RFC 3320", + keywords="sip, session initiation protocol, udvm, universal decompressor virtual machine", + doi="10.17487/RFC3320", + } + +@misc{rfc3321, + author="H. Hannu and J. Christoffersson and S. Forsgren and K.-C. Leung and Z. Liu and R. Price", + title="{Signaling Compression (SigComp) - Extended Operations}", + howpublished="RFC 3321 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3321", + pages="1--19", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4896", +url="https://www.rfc-editor.org/rfc/rfc3321.txt", + key="RFC 3321", + keywords="sip, session initiation protocol, udvm, universal decompressor virtual machine", + doi="10.17487/RFC3321", + } + +@misc{rfc3322, + author="H. Hannu", + title="{Signaling Compression (SigComp) Requirements \& Assumptions}", + howpublished="RFC 3322 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3322", + pages="1--13", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3322.txt", + key="RFC 3322", + keywords="sip, session initiation protocol, wireless, cellular, sdp, session description protocol", + doi="10.17487/RFC3322", + } + +@misc{rfc3323, + author="J. Peterson", + title="{A Privacy Mechanism for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3323 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3323", + pages="1--22", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3323.txt", + key="RFC 3323", + keywords="privacy service", + doi="10.17487/RFC3323", + } + +@misc{rfc3324, + author="M. Watson", + title="{Short Term Requirements for Network Asserted Identity}", + howpublished="RFC 3324 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3324", + pages="1--11", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3324.txt", + key="RFC 3324", + keywords="session initiation protocol, sip, ua, user agent", + doi="10.17487/RFC3324", + } + +@misc{rfc3325, + author="C. Jennings and J. Peterson and M. Watson", + title="{Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks}", + howpublished="RFC 3325 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3325", + pages="1--18", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5876, 8217", +url="https://www.rfc-editor.org/rfc/rfc3325.txt", + key="RFC 3325", + keywords="trust domain", + doi="10.17487/RFC3325", + } + +@misc{rfc3326, + author="H. Schulzrinne and D. Oran and G. Camarillo", + title="{The Reason Header Field for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3326 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3326", + pages="1--8", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3326.txt", + key="RFC 3326", + abstract={The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> 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]}, + keywords="heterogeneous error response forking problem, herfp", + doi="10.17487/RFC3326", + } + +@misc{rfc3327, + author="D. Willis and B. Hoeneisen", + title="{Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts}", + howpublished="RFC 3327 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3327", + pages="1--17", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5626", +url="https://www.rfc-editor.org/rfc/rfc3327.txt", + key="RFC 3327", + keywords="3gpp, register, contact, path, registrar, user agent, ua", + doi="10.17487/RFC3327", + } + +@misc{rfc3329, + author="J. Arkko and V. Torvinen and G. Camarillo and A. Niemi and T. Haukka", + title="{Security Mechanism Agreement for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3329 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3329", + pages="1--24", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3329.txt", + key="RFC 3329", + keywords="ua, user agent", + doi="10.17487/RFC3329", + } + +@misc{rfc3330, + author="IANA", + title="{Special-Use IPv4 Addresses}", + howpublished="RFC 3330 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3330", + pages="1--7", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5735", +url="https://www.rfc-editor.org/rfc/rfc3330.txt", + key="RFC 3330", + keywords="internet protocol, space assignments", + doi="10.17487/RFC3330", + } + +@misc{rfc3331, + author="K. Morneault and R. Dantu and G. Sidebottom and B. Bidulock and J. Heitz", + title="{Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer}", + howpublished="RFC 3331 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3331", + pages="1--94", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3331.txt", + key="RFC 3331", + keywords="sctp, stream control transmission protocol, sg, signaling gateway, media gateway controller, mgc", + doi="10.17487/RFC3331", + } + +@misc{rfc3332, + author="G. {Sidebottom (Ed.)} and K. {Morneault (Ed.)} and J. {Pastor-Balbas (Ed.)}", + title="{Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)}", + howpublished="RFC 3332 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3332", + pages="1--120", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4666", +url="https://www.rfc-editor.org/rfc/rfc3332.txt", + key="RFC 3332", + keywords="isup, sccp, sctp, stream control tranmission protocol, mgc, media gateway protocol, st, signalling gateway", + doi="10.17487/RFC3332", + } + +@misc{rfc3334, + author="T. Zseby and S. Zander and C. Carle", + title="{Policy-Based Accounting}", + howpublished="RFC 3334 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3334", + pages="1--44", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3334.txt", + key="RFC 3334", + keywords="measurement, metering, meter configuration, qos auditing, aaa, aaa architecture, inter-domain accounting", + doi="10.17487/RFC3334", + } + +@misc{rfc3335, + author="T. Harding and R. Drummond and C. Shih", + title="{MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet}", + howpublished="RFC 3335 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3335", + pages="1--29", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3335.txt", + key="RFC 3335", + keywords="multipurpose, internet mail extensions, edi", + doi="10.17487/RFC3335", + } + +@misc{rfc3336, + author="B. Thompson and T. Koren and B. Buffam", + title="{PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)}", + howpublished="RFC 3336 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3336", + pages="1--16", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3336.txt", + key="RFC 3336", + keywords="point-to-point, protocol, atm, aal2, datagram, packets", + doi="10.17487/RFC3336", + } + +@misc{rfc3337, + author="B. Thompson and T. Koren and B. Buffam", + title="{Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2}", + howpublished="RFC 3337 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3337", + pages="1--7", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3337.txt", + key="RFC 3337", + keywords="point-to-point, protocol, atm, aal2, encapsulation", + doi="10.17487/RFC3337", + } + +@misc{rfc3338, + author="S. Lee and M-K. Shin and Y-J. Kim and E. Nordmark and A. Durand", + title="{Dual Stack Hosts Using ``Bump-in-the-API'' (BIA)}", + howpublished="RFC 3338 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3338", + pages="1--17", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6535", +url="https://www.rfc-editor.org/rfc/rfc3338.txt", + key="RFC 3338", + keywords="", + doi="10.17487/RFC3338", + } + +@misc{rfc3339, + author="G. Klyne and C. Newman", + title="{Date and Time on the Internet: Timestamps}", + howpublished="RFC 3339 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3339", + pages="1--18", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3339.txt", + key="RFC 3339", + abstract={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.}, + keywords="gregorian calendar, iso", + doi="10.17487/RFC3339", + } + +@misc{rfc3340, + author="M. Rose and G. Klyne and D. Crocker", + title="{The Application Exchange Core}", + howpublished="RFC 3340 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3340", + pages="1--40", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3340.txt", + key="RFC 3340", + keywords="APEX", + doi="10.17487/RFC3340", + } + +@misc{rfc3341, + author="M. Rose and G. Klyne and D. Crocker", + title="{The Application Exchange (APEX) Access Service}", + howpublished="RFC 3341 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3341", + pages="1--26", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3341.txt", + key="RFC 3341", + keywords="APEX", + doi="10.17487/RFC3341", + } + +@misc{rfc3342, + author="E. Dixon and H. Franklin and J. Kint and G. Klyne and D. New and S. Pead and M. Rose and M. Schwartz", + title="{The Application Exchange (APEX) Option Party Pack, Part Deux!}", + howpublished="RFC 3342 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3342", + pages="1--22", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3342.txt", + key="RFC 3342", + keywords="datagram, service, core, relaying, mesh", + doi="10.17487/RFC3342", + } + +@misc{rfc3343, + author="M. Rose and G. Klyne and D. Crocker", + title="{The Application Exchange (APEX) Presence Service}", + howpublished="RFC 3343 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3343", + pages="1--23", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3343.txt", + key="RFC 3343", + keywords="endpoint", + doi="10.17487/RFC3343", + } + +@misc{rfc3344, + author="C. {Perkins (Ed.)}", + title="{IP Mobility Support for IPv4}", + howpublished="RFC 3344 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3344", + pages="1--99", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5944, updated by RFCs 4636, 4721", +url="https://www.rfc-editor.org/rfc/rfc3344.txt", + key="RFC 3344", + keywords="MOBILEIPSUPIP, Internet, Protocol", + doi="10.17487/RFC3344", + } + +@misc{rfc3345, + author="D. McPherson and V. Gill and D. Walton and A. Retana", + title="{Border Gateway Protocol (BGP) Persistent Route Oscillation Condition}", + howpublished="RFC 3345 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3345", + pages="1--19", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3345.txt", + key="RFC 3345", + keywords="idr, ibgp", + doi="10.17487/RFC3345", + } + +@misc{rfc3346, + author="J. Boyle and V. Gill and A. Hannan and D. Cooper and D. Awduche and B. Christian and W.S. Lai", + title="{Applicability Statement for Traffic Engineering with MPLS}", + howpublished="RFC 3346 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3346", + pages="1--14", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3346.txt", + key="RFC 3346", + keywords="multiprotocol label switching, te", + doi="10.17487/RFC3346", + } + +@misc{rfc3347, + author="M. Krueger and R. Haagens", + title="{Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations}", + howpublished="RFC 3347 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3347", + pages="1--26", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3347.txt", + key="RFC 3347", + keywords="scsi, tcp. storage, fibre channel", + doi="10.17487/RFC3347", + } + +@misc{rfc3348, + author="M. Gahrns and R. Cheng", + title="{The Internet Message Action Protocol (IMAP4) Child Mailbox Extension}", + howpublished="RFC 3348 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3348", + pages="1--6", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3348.txt", + key="RFC 3348", + keywords="children", + doi="10.17487/RFC3348", + } + +@misc{rfc3349, + author="M. Rose", + title="{A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force}", + howpublished="RFC 3349 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3349", + pages="1--6", + year=2002, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3349.txt", + key="RFC 3349", + keywords="beep", + doi="10.17487/RFC3349", + } + +@misc{rfc3351, + author="N. Charlton and M. Gasson and G. Gybels and M. Spanner and A. van Wijk", + title="{User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals}", + howpublished="RFC 3351 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3351", + pages="1--17", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3351.txt", + key="RFC 3351", + keywords="relay service, transcoding service, textphone", + doi="10.17487/RFC3351", + } + +@misc{rfc3352, + author="K. Zeilenga", + title="{Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status}", + howpublished="RFC 3352 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3352", + pages="1--4", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3352.txt", + key="RFC 3352", + keywords="CLDAP, CLDAP, Presentation, Address, Application, Entity, Title", + doi="10.17487/RFC3352", + } + +@misc{rfc3353, + author="D. Ooms and B. Sales and W. Livens and A. Acharya and F. Griffoul and F. Ansari", + title="{Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment}", + howpublished="RFC 3353 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3353", + pages="1--30", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3353.txt", + key="RFC 3353", + keywords="inrternet protocol, l2, multicast routing protocoln", + doi="10.17487/RFC3353", + } + +@misc{rfc3354, + author="D. {Eastlake 3rd}", + title="{Internet Open Trading Protocol Version 2 Requirements}", + howpublished="RFC 3354 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3354", + pages="1--6", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3354.txt", + key="RFC 3354", + keywords="payment, ecommerce, merchant, customer, delivery, signature, messaging, commerce, sale", + doi="10.17487/RFC3354", + } + +@misc{rfc3355, + author="A. Singh and R. Turner and R. Tio and S. Nanji", + title="{Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)}", + howpublished="RFC 3355 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3355", + pages="1--13", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3355.txt", + key="RFC 3355", + keywords="link, dial-up server, asynchronous transfer mode", + doi="10.17487/RFC3355", + } + +@misc{rfc3356, + author="G. Fishman and S. Bradner", + title="{Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines}", + howpublished="RFC 3356 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3356", + pages="1--12", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6756", +url="https://www.rfc-editor.org/rfc/rfc3356.txt", + key="RFC 3356", + keywords="internet, society, engineering, task, force", + doi="10.17487/RFC3356", + } + +@misc{rfc3357, + author="R. Koodli and R. Ravikanth", + title="{One-way Loss Pattern Sample Metrics}", + howpublished="RFC 3357 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3357", + pages="1--15", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3357.txt", + key="RFC 3357", + keywords="packets, voice, video, stream", + doi="10.17487/RFC3357", + } + +@misc{rfc3358, + author="T. Przygienda", + title="{Optional Checksums in Intermediate System to Intermediate System (ISIS)}", + howpublished="RFC 3358 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3358", + pages="1--4", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3358.txt", + key="RFC 3358", + keywords="type, length, value, complete sequence number, partial data", + doi="10.17487/RFC3358", + } + +@misc{rfc3359, + author="T. Przygienda", + title="{Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System}", + howpublished="RFC 3359 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3359", + pages="1--5", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3359.txt", + key="RFC 3359", + keywords="is-is, igp, osi, complete sequence number, partial data", + doi="10.17487/RFC3359", + } + +@misc{rfc3360, + author="S. Floyd", + title="{Inappropriate TCP Resets Considered Harmful}", + howpublished="RFC 3360 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3360", + pages="1--19", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3360.txt", + key="RFC 3360", + keywords="transmission control protocol, rst, bit, connection", + doi="10.17487/RFC3360", + } + +@misc{rfc3361, + author="H. Schulzrinne", + title="{Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers}", + howpublished="RFC 3361 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3361", + pages="1--7", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3361.txt", + key="RFC 3361", + keywords="proxy servers", + doi="10.17487/RFC3361", + } + +@misc{rfc3362, + author="G. Parsons", + title="{Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration}", + howpublished="RFC 3362 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3362", + pages="1--5", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3362.txt", + key="RFC 3362", + keywords="", + doi="10.17487/RFC3362", + } + +@misc{rfc3363, + author="R. Bush and A. Durand and B. Fink and O. Gudmundsson and T. Hain", + title="{Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)}", + howpublished="RFC 3363 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3363", + pages="1--6", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6672", +url="https://www.rfc-editor.org/rfc/rfc3363.txt", + key="RFC 3363", + keywords="reverse mapping, label binary", + doi="10.17487/RFC3363", + } + +@misc{rfc3364, + author="R. Austein", + title="{Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)}", + howpublished="RFC 3364 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3364", + pages="1--11", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3364.txt", + key="RFC 3364", + keywords="reverse mapping, rrs, resource records", + doi="10.17487/RFC3364", + } + +@misc{rfc3365, + author="J. Schiller", + title="{Strong Security Requirements for Internet Engineering Task Force Standard Protocols}", + howpublished="RFC 3365 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3365", + pages="1--8", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3365.txt", + key="RFC 3365", + keywords="ietf", + doi="10.17487/RFC3365", + } + +@misc{rfc3366, + author="G. Fairhurst and L. Wood", + title="{Advice to link designers on link Automatic Repeat reQuest (ARQ)}", + howpublished="RFC 3366 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3366", + pages="1--27", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3366.txt", + key="RFC 3366", + keywords="tcp/ip, subnetworks", + doi="10.17487/RFC3366", + } + +@misc{rfc3367, + author="N. Popp and M. Mealling and M. Moseley", + title="{Common Name Resolution Protocol (CNRP)}", + howpublished="RFC 3367 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3367", + pages="1--42", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3367.txt", + key="RFC 3367", + keywords="unique resource locators, client applications", + doi="10.17487/RFC3367", + } + +@misc{rfc3368, + author="M. Mealling", + title="{The 'go' URI Scheme for the Common Name Resolution Protocol}", + howpublished="RFC 3368 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3368", + pages="1--8", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3368.txt", + key="RFC 3368", + keywords="uniform resource identifier", + doi="10.17487/RFC3368", + } + +@misc{rfc3369, + author="R. Housley", + title="{Cryptographic Message Syntax (CMS)}", + howpublished="RFC 3369 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3369", + pages="1--52", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3852", +url="https://www.rfc-editor.org/rfc/rfc3369.txt", + key="RFC 3369", + keywords="digitally sign, authenticate, encrypt, arbitrary message content", + doi="10.17487/RFC3369", + } + +@misc{rfc3370, + author="R. Housley", + title="{Cryptographic Message Syntax (CMS) Algorithms}", + howpublished="RFC 3370 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3370", + pages="1--24", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5754", +url="https://www.rfc-editor.org/rfc/rfc3370.txt", + key="RFC 3370", + keywords="digitally sign, authenticate, encrypt, arbitrary message content", + doi="10.17487/RFC3370", + } + +@misc{rfc3371, + author="E. Caves and P. Calhoun and R. Wheeler", + title="{Layer Two Tunneling Protocol ``L2TP'' Management Information Base}", + howpublished="RFC 3371 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3371", + pages="1--70", + year=2002, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3371.txt", + key="RFC 3371", + keywords="mib", + doi="10.17487/RFC3371", + } + +@misc{rfc3372, + author="A. Vemuri and J. Peterson", + title="{Session Initiation Protocol for Telephones (SIP-T): Context and Architectures}", + howpublished="RFC 3372 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3372", + pages="1--23", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3372.txt", + key="RFC 3372", + keywords="pstn, public switch telephone network", + doi="10.17487/RFC3372", + } + +@misc{rfc3373, + author="D. Katz and R. Saluja", + title="{Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies}", + howpublished="RFC 3373 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3373", + pages="1--9", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5303", +url="https://www.rfc-editor.org/rfc/rfc3373.txt", + key="RFC 3373", + keywords="links, handshake", + doi="10.17487/RFC3373", + } + +@misc{rfc3374, + author="J. {Kempf (Ed.)}", + title="{Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network}", + howpublished="RFC 3374 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3374", + pages="1--14", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3374.txt", + key="RFC 3374", + keywords="aaa, qos, authentication authorization accounting, quality of service, header compression", + doi="10.17487/RFC3374", + } + +@misc{rfc3375, + author="S. Hollenbeck", + title="{Generic Registry-Registrar Protocol Requirements}", + howpublished="RFC 3375 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3375", + pages="1--21", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3375.txt", + key="RFC 3375", + keywords="rrp, client server, domain names", + doi="10.17487/RFC3375", + } + +@misc{rfc3376, + author="B. Cain and S. Deering and I. Kouvelas and B. Fenner and A. Thyagarajan", + title="{Internet Group Management Protocol, Version 3}", + howpublished="RFC 3376 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3376", + pages="1--53", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4604", +url="https://www.rfc-editor.org/rfc/rfc3376.txt", + key="RFC 3376", + keywords="IGMP, IGMP, multicast, routing, IP, Internet Protocol", + doi="10.17487/RFC3376", + } + +@misc{rfc3377, + author="J. Hodges and R. Morgan", + title="{Lightweight Directory Access Protocol (v3): Technical Specification}", + howpublished="RFC 3377 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3377", + pages="1--6", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4510", +url="https://www.rfc-editor.org/rfc/rfc3377.txt", + key="RFC 3377", + keywords="ldap, ldapv3", + doi="10.17487/RFC3377", + } + +@misc{rfc3378, + author="R. Housley and S. Hollenbeck", + title="{EtherIP: Tunneling Ethernet Frames in IP Datagrams}", + howpublished="RFC 3378 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3378", + pages="1--9", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3378.txt", + key="RFC 3378", + keywords="internet protocol, ip 97", + doi="10.17487/RFC3378", + } + +@misc{rfc3379, + author="D. Pinkas and R. Housley", + title="{Delegated Path Validation and Delegated Path Discovery Protocol Requirements}", + howpublished="RFC 3379 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3379", + pages="1--15", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3379.txt", + key="RFC 3379", + keywords="dpv, dpd, public, key, certificates", + doi="10.17487/RFC3379", + } + +@misc{rfc3380, + author="T. Hastings and R. Herriot and C. Kugler and H. Lewis", + title="{Internet Printing Protocol (IPP): Job and Printer Set Operations}", + howpublished="RFC 3380 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3380", + pages="1--59", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3380.txt", + key="RFC 3380", + keywords="IPP-E-T, IPP, application, media-type, media, type", + doi="10.17487/RFC3380", + } + +@misc{rfc3381, + author="T. Hastings and H. Lewis and R. Bergman", + title="{Internet Printing Protocol (IPP): Job Progress Attributes}", + howpublished="RFC 3381 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3381", + pages="1--17", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8011", +url="https://www.rfc-editor.org/rfc/rfc3381.txt", + key="RFC 3381", + keywords="IPP-E-T, IPP, application, media-type, media, type", + doi="10.17487/RFC3381", + } + +@misc{rfc3382, + author="R. deBry and T. Hastings and R. Herriot and K. Ocke and P. Zehler", + title="{Internet Printing Protocol (IPP): The 'collection' attribute syntax}", + howpublished="RFC 3382 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3382", + pages="1--38", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 8010, 8011", +url="https://www.rfc-editor.org/rfc/rfc3382.txt", + key="RFC 3382", + keywords="IPP-E-T, IPP, application, media-type, media, type", + doi="10.17487/RFC3382", + } + +@misc{rfc3383, + author="K. Zeilenga", + title="{Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)}", + howpublished="RFC 3383 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3383", + pages="1--23", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4520", +url="https://www.rfc-editor.org/rfc/rfc3383.txt", + key="RFC 3383", + keywords="guidelines, extensible values", + doi="10.17487/RFC3383", + } + +@misc{rfc3384, + author="E. Stokes and R. Weiser and R. Moats and R. Huber", + title="{Lightweight Directory Access Protocol (version 3) Replication Requirements}", + howpublished="RFC 3384 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3384", + pages="1--31", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3384.txt", + key="RFC 3384", + keywords="ldapv3, data interoperability, synchronization, multi-master", + doi="10.17487/RFC3384", + } + +@misc{rfc3385, + author="D. Sheinwald and J. Satran and P. Thaler and V. Cavanna", + title="{Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations}", + howpublished="RFC 3385 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3385", + pages="1--23", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3385.txt", + key="RFC 3385", + keywords="error detection code", + doi="10.17487/RFC3385", + } + +@misc{rfc3386, + author="W. {Lai (Ed.)} and D. {McDysan (Ed.)}", + title="{Network Hierarchy and Multilayer Survivability}", + howpublished="RFC 3386 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3386", + pages="1--27", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3386.txt", + key="RFC 3386", + keywords="service, provider, packet networks, protection, restoration, recovery", + doi="10.17487/RFC3386", + } + +@misc{rfc3387, + author="M. Eder and H. Chaskar and S. Nag", + title="{Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network}", + howpublished="RFC 3387 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3387", + pages="1--19", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3387.txt", + key="RFC 3387", + keywords="internet protocol, packts, fuel-service", + doi="10.17487/RFC3387", + } + +@misc{rfc3388, + author="G. Camarillo and G. Eriksson and J. Holler and H. Schulzrinne", + title="{Grouping of Media Lines in the Session Description Protocol (SDP)}", + howpublished="RFC 3388 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3388", + pages="1--11", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5888", +url="https://www.rfc-editor.org/rfc/rfc3388.txt", + key="RFC 3388", + keywords="formats, attribute, port, host, interfaces, fid, flow identification, lip synchronization, ls", + doi="10.17487/RFC3388", + } + +@misc{rfc3389, + author="R. Zopf", + title="{Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)}", + howpublished="RFC 3389 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3389", + pages="1--8", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3389.txt", + key="RFC 3389", + keywords="codecs, audio, multimedia", + doi="10.17487/RFC3389", + } + +@misc{rfc3390, + author="M. Allman and S. Floyd and C. Partridge", + title="{Increasing TCP's Initial Window}", + howpublished="RFC 3390 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3390", + pages="1--15", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3390.txt", + key="RFC 3390", + keywords="transmission control protocol", + doi="10.17487/RFC3390", + } + +@misc{rfc3391, + author="R. Herriot", + title="{The MIME Application/Vnd.pwg-multiplexed Content-Type}", + howpublished="RFC 3391 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3391", + pages="1--25", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3391.txt", + key="RFC 3391", + keywords="multipurpose internet mail extensions, media type", + doi="10.17487/RFC3391", + } + +@misc{rfc3392, + author="R. Chandra and J. Scudder", + title="{Capabilities Advertisement with BGP-4}", + howpublished="RFC 3392 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3392", + pages="1--6", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5492", +url="https://www.rfc-editor.org/rfc/rfc3392.txt", + key="RFC 3392", + keywords=" border, gateway, protocol", + doi="10.17487/RFC3392", + } + +@misc{rfc3393, + author="C. Demichelis and P. Chimento", + title="{IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)}", + howpublished="RFC 3393 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3393", + pages="1--21", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3393.txt", + key="RFC 3393", + keywords=" internet protocol, ipdv", + doi="10.17487/RFC3393", + } + +@misc{rfc3394, + author="J. Schaad and R. Housley", + title="{Advanced Encryption Standard (AES) Key Wrap Algorithm}", + howpublished="RFC 3394 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3394", + pages="1--41", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3394.txt", + key="RFC 3394", + keywords="security", + doi="10.17487/RFC3394", + } + +@misc{rfc3395, + author="A. Bierman and C. Bucci and R. Dietz and A. Warth", + title="{Remote Network Monitoring MIB Protocol Identifier Reference Extensions}", + howpublished="RFC 3395 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3395", + pages="1--21", + year=2002, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3395.txt", + key="RFC 3395", + keywords="RMON-MIB, management, information, base", + doi="10.17487/RFC3395", + } + +@misc{rfc3396, + author="T. Lemon and S. Cheshire", + title="{Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)}", + howpublished="RFC 3396 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3396", + pages="1--9", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3396.txt", + key="RFC 3396", + keywords="octet, packet, code", + doi="10.17487/RFC3396", + } + +@misc{rfc3397, + author="B. Aboba and S. Cheshire", + title="{Dynamic Host Configuration Protocol (DHCP) Domain Search Option}", + howpublished="RFC 3397 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3397", + pages="1--8", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3397.txt", + key="RFC 3397", + keywords="dns, client, client server", + doi="10.17487/RFC3397", + } + +@misc{rfc3398, + author="G. Camarillo and A. B. Roach and J. Peterson and L. Ong", + title="{Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping}", + howpublished="RFC 3398 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3398", + pages="1--68", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3398.txt", + key="RFC 3398", + keywords="signaling system no. 7, ss7, pstn, public switched telephone network", + doi="10.17487/RFC3398", + } + +@misc{rfc3401, + author="M. Mealling", + title="{Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS}", + howpublished="RFC 3401 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3401", + pages="1--6", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3401.txt", + key="RFC 3401", + abstract={This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.}, + keywords="NAPTR, domain name system, RR", + doi="10.17487/RFC3401", + } + +@misc{rfc3402, + author="M. Mealling", + title="{Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm}", + howpublished="RFC 3402 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3402", + pages="1--17", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3402.txt", + key="RFC 3402", + abstract={This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]}, + keywords="NAPTR, domain name system, RR", + doi="10.17487/RFC3402", + } + +@misc{rfc3403, + author="M. Mealling", + title="{Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database}", + howpublished="RFC 3403 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3403", + pages="1--14", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3403.txt", + key="RFC 3403", + abstract={This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]}, + keywords="NAPTR, domain name system, RR", + doi="10.17487/RFC3403", + } + +@misc{rfc3404, + author="M. Mealling", + title="{Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)}", + howpublished="RFC 3404 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3404", + pages="1--18", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3404.txt", + key="RFC 3404", + abstract={This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]}, + keywords="NAPTR, domain name system, RR", + doi="10.17487/RFC3404", + } + +@misc{rfc3405, + author="M. Mealling", + title="{Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures}", + howpublished="RFC 3405 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3405", + pages="1--10", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3405.txt", + key="RFC 3405", + abstract={This document is fifth in a series that is completely specified in ``Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS'' (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="uniform resource identifiers", + doi="10.17487/RFC3405", + } + +@misc{rfc3406, + author="L. Daigle and D. van Gulik and R. Iannella and P. Faltstrom", + title="{Uniform Resource Names (URN) Namespace Definition Mechanisms}", + howpublished="RFC 3406 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3406", + pages="1--22", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8141", +url="https://www.rfc-editor.org/rfc/rfc3406.txt", + key="RFC 3406", + abstract={This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) ``namespaces''. The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual ``namespaces'' within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="namespaces, applications, structure", + doi="10.17487/RFC3406", + } + +@misc{rfc3407, + author="F. Andreasen", + title="{Session Description Protocol (SDP) Simple Capability Declaration}", + howpublished="RFC 3407 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3407", + pages="1--10", + year=2002, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3407.txt", + key="RFC 3407", + abstract={This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS-TRACK]}, + keywords="SDPng", + doi="10.17487/RFC3407", + } + +@misc{rfc3408, + author="Z. Liu and K. Le", + title="{Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile}", + howpublished="RFC 3408 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3408", + pages="1--7", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3408.txt", + key="RFC 3408", + abstract={This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS-TRACK]}, + keywords="single-octet, packet size", + doi="10.17487/RFC3408", + } + +@misc{rfc3409, + author="K. Svanbro", + title="{Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression}", + howpublished="RFC 3409 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3409", + pages="1--11", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3409.txt", + key="RFC 3409", + abstract={This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community.}, + keywords="rohc, algorithms", + doi="10.17487/RFC3409", + } + +@misc{rfc3410, + author="J. Case and R. Mundy and D. Partain and B. Stewart", + title="{Introduction and Applicability Statements for Internet-Standard Management Framework}", + howpublished="RFC 3410 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3410", + pages="1--27", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3410.txt", + key="RFC 3410", + abstract={The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.}, + keywords="snmp, simple, protocol, snmpv3", + doi="10.17487/RFC3410", + } + +@misc{rfc3411, + author="D. Harrington and R. Presuhn and B. Wijnen", + title="{An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks}", + howpublished="RFC 3411 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3411", + pages="1--64", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5343, 5590", +url="https://www.rfc-editor.org/rfc/rfc3411.txt", + key="RFC 3411", + abstract={This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]}, + keywords="ARCH-SNMP, simple, protocol, network, management", + doi="10.17487/RFC3411", + } + +@misc{rfc3412, + author="J. Case and D. Harrington and R. Presuhn and B. Wijnen", + title="{Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 3412 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3412", + pages="1--43", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5590", +url="https://www.rfc-editor.org/rfc/rfc3412.txt", + key="RFC 3412", + abstract={This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS-TRACK]}, + keywords="MPD-SNMP, processing, models, multiple", + doi="10.17487/RFC3412", + } + +@misc{rfc3413, + author="D. Levi and P. Meyer and B. Stewart", + title="{Simple Network Management Protocol (SNMP) Applications}", + howpublished="RFC 3413 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3413", + pages="1--74", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3413.txt", + key="RFC 3413", + abstract={This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS-TRACK]}, + keywords="SNMP-APP, simple, network, management, protocol, proxy, operations, command", + doi="10.17487/RFC3413", + } + +@misc{rfc3414, + author="U. Blumenthal and B. Wijnen", + title="{User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)}", + howpublished="RFC 3414 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3414", + pages="1--88", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5590", +url="https://www.rfc-editor.org/rfc/rfc3414.txt", + key="RFC 3414", + abstract={This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]}, + keywords="USM-SNMPV3, message, level, mib, information, base", + doi="10.17487/RFC3414", + } + +@misc{rfc3415, + author="B. Wijnen and R. Presuhn and K. McCloghrie", + title="{View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 3415 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3415", + pages="1--39", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3415.txt", + key="RFC 3415", + abstract={This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS-TRACK]}, + keywords="VACM-SNMP, mib, information, base", + doi="10.17487/RFC3415", + } + +@misc{rfc3416, + author="R. {Presuhn (Ed.)}", + title="{Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 3416 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3416", + pages="1--31", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3416.txt", + key="RFC 3416", + abstract={This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS-TRACK]}, + keywords="OPS-MIB, Simple, Network, Management, Protocol, Version 2", + doi="10.17487/RFC3416", + } + +@misc{rfc3417, + author="R. {Presuhn (Ed.)}", + title="{Transport Mappings for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 3417 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3417", + pages="1--19", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4789, 5590", +url="https://www.rfc-editor.org/rfc/rfc3417.txt", + key="RFC 3417", + abstract={This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS-TRACK]}, + keywords="TRANS-MIB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC3417", + } + +@misc{rfc3418, + author="R. {Presuhn (Ed.)}", + title="{Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 3418 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3418", + pages="1--26", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3418.txt", + key="RFC 3418", + abstract={This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]}, + keywords="SNMPv2-MIB, Simple, Network, Management, Protocol, Version, 2", + doi="10.17487/RFC3418", + } + +@misc{rfc3419, + author="M. Daniele and J. Schoenwaelder", + title="{Textual Conventions for Transport Addresses}", + howpublished="RFC 3419 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3419", + pages="1--18", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3419.txt", + key="RFC 3419", + abstract={This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS-TRACK]}, + keywords="mib, management information base", + doi="10.17487/RFC3419", + } + +@misc{rfc3420, + author="R. Sparks", + title="{Internet Media Type message/sipfrag}", + howpublished="RFC 3420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3420", + pages="1--8", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3420.txt", + key="RFC 3420", + abstract={This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS-TRACK]}, + keywords="mime, multipurpose internet mail extesions", + doi="10.17487/RFC3420", + } + +@misc{rfc3421, + author="W. Zhao and H. Schulzrinne and E. Guttman and C. Bisdikian and W. Jerome", + title="{Select and Sort Extensions for the Service Location Protocol (SLP)}", + howpublished="RFC 3421 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3421", + pages="1--8", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3421.txt", + key="RFC 3421", + abstract={This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community.}, + keywords="user agent, url, service reply, ua, svrrply", + doi="10.17487/RFC3421", + } + +@misc{rfc3422, + author="O. Okamoto and M. Maruyama and T. Sajima", + title="{Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)}", + howpublished="RFC 3422 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3422", + pages="1--19", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3422.txt", + key="RFC 3422", + abstract={This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community.}, + keywords="tunneling, ethernet frames", + doi="10.17487/RFC3422", + } + +@misc{rfc3423, + author="K. Zhang and E. Elkin", + title="{XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0}", + howpublished="RFC 3423 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3423", + pages="1--45", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3423.txt", + key="RFC 3423", + abstract={This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community.}, + keywords="data, delivery, message, format, template-based, client/server", + doi="10.17487/RFC3423", + } + +@misc{rfc3424, + author="L. {Daigle (Ed.)} and IAB", + title="{IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation}", + howpublished="RFC 3424 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3424", + pages="1--9", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3424.txt", + key="RFC 3424", + abstract={As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for ``UNilateral Self-Address Fixing (UNSAF)'' processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.}, + keywords="nat, middleboxes", + doi="10.17487/RFC3424", + } + +@misc{rfc3425, + author="D. Lawrence", + title="{Obsoleting IQUERY}", + howpublished="RFC 3425 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3425", + pages="1--5", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3425.txt", + key="RFC 3425", + abstract={The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK]}, + keywords="dns lookups, domain", + doi="10.17487/RFC3425", + } + +@misc{rfc3426, + author="S. Floyd", + title="{General Architectural and Policy Considerations}", + howpublished="RFC 3426 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3426", + pages="1--23", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3426.txt", + key="RFC 3426", + abstract={This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community.}, + keywords="internet architecture", + doi="10.17487/RFC3426", + } + +@misc{rfc3427, + author="A. Mankin and S. Bradner and R. Mahy and D. Willis and J. Ott and B. Rosen", + title="{Change Process for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3427 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3427", + pages="1--12", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5727, updated by RFCs 3968, 3969", +url="https://www.rfc-editor.org/rfc/rfc3427.txt", + key="RFC 3427", + abstract={This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="sipping", + doi="10.17487/RFC3427", + } + +@misc{rfc3428, + author="B. {Campbell (Ed.)} and J. Rosenberg and H. Schulzrinne and C. Huitema and D. Gurle", + title="{Session Initiation Protocol (SIP) Extension for Instant Messaging}", + howpublished="RFC 3428 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3428", + pages="1--18", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3428.txt", + key="RFC 3428", + abstract={Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS-TRACK]}, + keywords="im, message method", + doi="10.17487/RFC3428", + } + +@misc{rfc3429, + author="H. Ohta", + title="{Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions}", + howpublished="RFC 3429 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3429", + pages="1--6", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3429.txt", + key="RFC 3429", + abstract={This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community.}, + keywords="reserved lavel values", + doi="10.17487/RFC3429", + } + +@misc{rfc3430, + author="J. Schoenwaelder", + title="{Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping}", + howpublished="RFC 3430 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3430", + pages="1--10", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3430.txt", + key="RFC 3430", + abstract={This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community.}, + keywords="snmp, tcp", + doi="10.17487/RFC3430", + } + +@misc{rfc3431, + author="W. Segmuller", + title="{Sieve Extension: Relational Tests}", + howpublished="RFC 3431 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3431", + pages="1--8", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5231", +url="https://www.rfc-editor.org/rfc/rfc3431.txt", + key="RFC 3431", + abstract={This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS-TRACK]}, + keywords="sieve mail, filtering language", + doi="10.17487/RFC3431", + } + +@misc{rfc3432, + author="V. Raisanen and G. Grotefeld and A. Morton", + title="{Network performance measurement with periodic streams}", + howpublished="RFC 3432 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3432", + pages="1--23", + year=2002, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3432.txt", + key="RFC 3432", + abstract={This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]}, + keywords="cbr, constant bit rate, periodic sampling, poisson sampling", + doi="10.17487/RFC3432", + } + +@misc{rfc3433, + author="A. Bierman and D. Romascanu and K.C. Norseth", + title="{Entity Sensor Management Information Base}", + howpublished="RFC 3433 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3433", + pages="1--17", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3433.txt", + key="RFC 3433", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS-TRACK]}, + keywords="mib, physical sensors, snmp", + doi="10.17487/RFC3433", + } + +@misc{rfc3434, + author="A. Bierman and K. McCloghrie", + title="{Remote Monitoring MIB Extensions for High Capacity Alarms}", + howpublished="RFC 3434 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3434", + pages="1--24", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3434.txt", + key="RFC 3434", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS-TRACK]}, + keywords="rmon, counter64, smiv2, snmp", + doi="10.17487/RFC3434", + } + +@misc{rfc3435, + author="F. Andreasen and B. Foster", + title="{Media Gateway Control Protocol (MGCP) Version 1.0}", + howpublished="RFC 3435 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3435", + pages="1--210", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3661", +url="https://www.rfc-editor.org/rfc/rfc3435.txt", + key="RFC 3435", + abstract={This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control ``intelligence'', and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which d efine 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.}, + keywords="voice, IP, internet, VoIP", + doi="10.17487/RFC3435", + } + +@misc{rfc3436, + author="A. Jungmaier and E. Rescorla and M. Tuexen", + title="{Transport Layer Security over Stream Control Transmission Protocol}", + howpublished="RFC 3436 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3436", + pages="1--9", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3436.txt", + key="RFC 3436", + abstract={This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]}, + keywords="sctp, tls", + doi="10.17487/RFC3436", + } + +@misc{rfc3437, + author="W. Palter and W. Townsley", + title="{Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation}", + howpublished="RFC 3437 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3437", + pages="1--10", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3437.txt", + key="RFC 3437", + abstract={This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism f or communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS-TRACK]}, + keywords="l2tp, lcp", + doi="10.17487/RFC3437", + } + +@misc{rfc3438, + author="W. Townsley", + title="{Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update}", + howpublished="RFC 3438 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3438", + pages="1--5", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3438.txt", + key="RFC 3438", + abstract={This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="L2TP, ppp, point-to-point, protocol, packets", + doi="10.17487/RFC3438", + } + +@misc{rfc3439, + author="R. Bush and D. Meyer", + title="{Some Internet Architectural Guidelines and Philosophy}", + howpublished="RFC 3439 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3439", + pages="1--28", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3439.txt", + key="RFC 3439", + abstract={This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community.}, + keywords="IAB", + doi="10.17487/RFC3439", + } + +@misc{rfc3440, + author="F. Ly and G. Bathrick", + title="{Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines}", + howpublished="RFC 3440 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3440", + pages="1--36", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3440.txt", + key="RFC 3440", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS-TRACK]}, + keywords="simple network management protocol, mib, adsl, asymmetric digital subscriber line", + doi="10.17487/RFC3440", + } + +@misc{rfc3441, + author="R. Kumar", + title="{Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)}", + howpublished="RFC 3441 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3441", + pages="1--50", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3441.txt", + key="RFC 3441", + abstract={This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community.}, + keywords="connection, codec profile", + doi="10.17487/RFC3441", + } + +@misc{rfc3442, + author="T. Lemon and S. Cheshire and B. Volz", + title="{The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4}", + howpublished="RFC 3442 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3442", + pages="1--9", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3442.txt", + key="RFC 3442", + abstract={This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS-TRACK]}, + keywords="Dynamic, Host, Configuration, Protocol, Bootstrap", + doi="10.17487/RFC3442", + } + +@misc{rfc3443, + author="P. Agarwal and B. Akyol", + title="{Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks}", + howpublished="RFC 3443 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3443", + pages="1--10", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc3443.txt", + key="RFC 3443", + abstract={This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, ``MPLS Label Stack Encoding''. TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both ``push'' and ``pop'' cases. The document also complements RFC 3270, ``MPLS Support of Differentiated Services'' and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS-TRACK]}, + keywords="label stack encoding, uniform model, pipe model", + doi="10.17487/RFC3443", + } + +@misc{rfc3444, + author="A. Pras and J. Schoenwaelder", + title="{On the Difference between Information Models and Data Models}", + howpublished="RFC 3444 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3444", + pages="1--8", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3444.txt", + key="RFC 3444", + abstract={There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.}, + keywords="network management", + doi="10.17487/RFC3444", + } + +@misc{rfc3445, + author="D. Massey and S. Rose", + title="{Limiting the Scope of the KEY Resource Record (RR)}", + howpublished="RFC 3445 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3445", + pages="1--10", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035", +url="https://www.rfc-editor.org/rfc/rfc3445.txt", + key="RFC 3445", + abstract={This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS-TRACK]}, + keywords="DNS-SECEXT, dns, authentication", + doi="10.17487/RFC3445", + } + +@misc{rfc3446, + author="D. Kim and D. Meyer and H. Kilmer and D. Farinacci", + title="{Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)}", + howpublished="RFC 3446 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3446", + pages="1--7", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3446.txt", + key="RFC 3446", + abstract={This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.}, + keywords="sparse mode, single shared-tree", + doi="10.17487/RFC3446", + } + +@misc{rfc3447, + author="J. Jonsson and B. Kaliski", + title="{Public-Key Cryptography Standards (PKCS) \#1: RSA Cryptography Specifications Version 2.1}", + howpublished="RFC 3447 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3447", + pages="1--72", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8017", +url="https://www.rfc-editor.org/rfc/rfc3447.txt", + key="RFC 3447", + abstract={This memo represents a republication of PKCS \#1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS \#1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.}, + keywords="data, public, key, cryptosystem", + doi="10.17487/RFC3447", + } + +@misc{rfc3448, + author="M. Handley and S. Floyd and J. Padhye and J. Widmer", + title="{TCP Friendly Rate Control (TFRC): Protocol Specification}", + howpublished="RFC 3448 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3448", + pages="1--24", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5348", +url="https://www.rfc-editor.org/rfc/rfc3448.txt", + key="RFC 3448", + abstract={This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]}, + keywords="congestion, unicast, streaming media", + doi="10.17487/RFC3448", + } + +@misc{rfc3449, + author="H. Balakrishnan and V. Padmanabhan and G. Fairhurst and M. Sooriyabandara", + title="{TCP Performance Implications of Network Path Asymmetry}", + howpublished="RFC 3449 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3449", + pages="1--41", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3449.txt", + key="RFC 3449", + abstract={This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's ac knowledgment-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.}, + keywords="links, sender, receiver, ack", + doi="10.17487/RFC3449", + } + +@misc{rfc3450, + author="M. Luby and J. Gemmell and L. Vicisano and L. Rizzo and J. Crowcroft", + title="{Asynchronous Layered Coding (ALC) Protocol Instantiation}", + howpublished="RFC 3450 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3450", + pages="1--34", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5775", +url="https://www.rfc-editor.org/rfc/rfc3450.txt", + key="RFC 3450", + abstract={This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community.}, + keywords="content, delivery, congestion, control, receivers", + doi="10.17487/RFC3450", + } + +@misc{rfc3451, + author="M. Luby and J. Gemmell and L. Vicisano and L. Rizzo and M. Handley and J. Crowcroft", + title="{Layered Coding Transport (LCT) Building Block}", + howpublished="RFC 3451 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3451", + pages="1--29", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5651", +url="https://www.rfc-editor.org/rfc/rfc3451.txt", + key="RFC 3451", + abstract={Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community.}, + keywords="content, stream, delivery, multicast, internet protocol", + doi="10.17487/RFC3451", + } + +@misc{rfc3452, + author="M. Luby and L. Vicisano and J. Gemmell and L. Rizzo and M. Handley and J. Crowcroft", + title="{Forward Error Correction (FEC) Building Block}", + howpublished="RFC 3452 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3452", + pages="1--16", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5052, 5445", +url="https://www.rfc-editor.org/rfc/rfc3452.txt", + key="RFC 3452", + abstract={This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, ``The Use of Forward Error Correction (FEC) in Reliable Multicast''. This memo defines an Experimental Protocol for the Internet community.}, + keywords="content, stream, delivery, multicast, internet protocol", + doi="10.17487/RFC3452", + } + +@misc{rfc3453, + author="M. Luby and L. Vicisano and J. Gemmell and L. Rizzo and M. Handley and J. Crowcroft", + title="{The Use of Forward Error Correction (FEC) in Reliable Multicast}", + howpublished="RFC 3453 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3453", + pages="1--18", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3453.txt", + key="RFC 3453", + abstract={This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community.}, + keywords="ip, internet protocol, data transport", + doi="10.17487/RFC3453", + } + +@misc{rfc3454, + author="P. Hoffman and M. Blanchet", + title="{Preparation of Internationalized Strings (``stringprep'')}", + howpublished="RFC 3454 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3454", + pages="1--91", + year=2002, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7564", +url="https://www.rfc-editor.org/rfc/rfc3454.txt", + key="RFC 3454", + abstract={This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS-TRACK]}, + keywords="unicode text, internationalization", + doi="10.17487/RFC3454", + } + +@misc{rfc3455, + author="M. Garcia-Martin and E. Henrikson and D. Mills", + title="{Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)}", + howpublished="RFC 3455 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3455", + pages="1--34", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7315", +url="https://www.rfc-editor.org/rfc/rfc3455.txt", + key="RFC 3455", + abstract={This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.}, + doi="10.17487/RFC3455", + } + +@misc{rfc3456, + author="B. Patel and B. Aboba and S. Kelly and V. Gupta", + title="{Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode}", + howpublished="RFC 3456 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3456", + pages="1--18", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3456.txt", + key="RFC 3456", + abstract={This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a ``virtual'' address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS-TRACK]}, + keywords="security, internet protocol", + doi="10.17487/RFC3456", + } + +@misc{rfc3457, + author="S. Kelly and S. Ramamoorthi", + title="{Requirements for IPsec Remote Access Scenarios}", + howpublished="RFC 3457 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3457", + pages="1--31", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3457.txt", + key="RFC 3457", + abstract={IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community.}, + keywords="ipsra, common remote access scenarios", + doi="10.17487/RFC3457", + } + +@misc{rfc3458, + author="E. Burger and E. Candell and C. Eliot and G. Klyne", + title="{Message Context for Internet Mail}", + howpublished="RFC 3458 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3458", + pages="1--17", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3938", +url="https://www.rfc-editor.org/rfc/rfc3458.txt", + key="RFC 3458", + abstract={This memo describes a new RFC 2822 message header, ``Message-Context''. This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]}, + keywords="user agent, ua", + doi="10.17487/RFC3458", + } + +@misc{rfc3459, + author="E. Burger", + title="{Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter}", + howpublished="RFC 3459 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3459", + pages="1--24", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5621", +url="https://www.rfc-editor.org/rfc/rfc3459.txt", + key="RFC 3459", + abstract={This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process . [STANDARDS-TRACK]}, + keywords="body parts, content-disposition", + doi="10.17487/RFC3459", + } + +@misc{rfc3460, + author="B. {Moore (Ed.)}", + title="{Policy Core Information Model (PCIM) Extensions}", + howpublished="RFC 3460 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3460", + pages="1--93", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3460.txt", + key="RFC 3460", + abstract={This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS-TRACK]}, + keywords="CIM, common, schema, object-oriented", + doi="10.17487/RFC3460", + } + +@misc{rfc3461, + author="K. Moore", + title="{Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)}", + howpublished="RFC 3461 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3461", + pages="1--38", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3798, 3885, 5337, 6533, 8098", +url="https://www.rfc-editor.org/rfc/rfc3461.txt", + key="RFC 3461", + abstract={This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]}, + keywords="SMTP-DSN, simple, mail, transfer, protocol", + doi="10.17487/RFC3461", + } + +@misc{rfc3462, + author="G. Vaudreuil", + title="{The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages}", + howpublished="RFC 3462 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3462", + pages="1--7", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6522, updated by RFC 5337", +url="https://www.rfc-editor.org/rfc/rfc3462.txt", + key="RFC 3462", + abstract={The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general ``family'' or ``container'' type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS-TRACK]}, + keywords="MIME-RPT, Multipurpose, Internet, Mail, Extensions", + doi="10.17487/RFC3462", + } + +@misc{rfc3463, + author="G. Vaudreuil", + title="{Enhanced Mail System Status Codes}", + howpublished="RFC 3463 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3463", + pages="1--16", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3886, 4468, 4865, 4954, 5248", +url="https://www.rfc-editor.org/rfc/rfc3463.txt", + key="RFC 3463", + abstract={This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK]}, + keywords="EMS-CODE, simple, mail, transfer, protocol, SMTP", + doi="10.17487/RFC3463", + } + +@misc{rfc3464, + author="K. Moore and G. Vaudreuil", + title="{An Extensible Message Format for Delivery Status Notifications}", + howpublished="RFC 3464 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3464", + pages="1--40", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4865, 5337, 6533", +url="https://www.rfc-editor.org/rfc/rfc3464.txt", + key="RFC 3464", + abstract={This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called ``Local Area Network (LAN)-based'' systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of ``foreign'' addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support ``tunneling'' of foreign notifications through Internet mail. [STANDARDS-TRACK]} , + keywords="DSN, Multipurpose, Internet, Mail, Extensions, Content, Type", + doi="10.17487/RFC3464", + } + +@misc{rfc3465, + author="M. Allman", + title="{TCP Congestion Control with Appropriate Byte Counting (ABC)}", + howpublished="RFC 3465 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3465", + pages="1--10", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3465.txt", + key="RFC 3465", + abstract={This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community.}, + keywords="transmission control protocol, security performance", + doi="10.17487/RFC3465", + } + +@misc{rfc3466, + author="M. Day and B. Cain and G. Tomlinson and P. Rzewski", + title="{A Model for Content Internetworking (CDI)}", + howpublished="RFC 3466 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3466", + pages="1--17", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7336", +url="https://www.rfc-editor.org/rfc/rfc3466.txt", + key="RFC 3466", + abstract={Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called ``content peering'' or ``CDN peering''. A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community.}, + keywords="distribution peering", + doi="10.17487/RFC3466", + } + +@misc{rfc3467, + author="J. Klensin", + title="{Role of the Domain Name System (DNS)}", + howpublished="RFC 3467 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3467", + pages="1--31", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3467.txt", + key="RFC 3467", + abstract={This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.}, + keywords="history, internationalization, unicode, ascii, multilingual names", + doi="10.17487/RFC3467", + } + +@misc{rfc3468, + author="L. Andersson and G. Swallow", + title="{The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols}", + howpublished="RFC 3468 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3468", + pages="1--11", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3468.txt", + key="RFC 3468", + abstract={This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on ``Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels'' (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to ``Constraint-Based LSP Setup using Label Distribution Protocol (LDP)'' (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community.}, + keywords="rsvp-te, ldp, resource reservation protocol label distribution", + doi="10.17487/RFC3468", + } + +@misc{rfc3469, + author="V. {Sharma (Ed.)} and F. {Hellstrand (Ed.)}", + title="{Framework for Multi-Protocol Label Switching (MPLS)-based Recovery}", + howpublished="RFC 3469 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3469", + pages="1--40", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc3469.txt", + key="RFC 3469", + abstract={Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community.}, + keywords="routing traffic", + doi="10.17487/RFC3469", + } + +@misc{rfc3470, + author="S. Hollenbeck and M. Rose and L. Masinter", + title="{Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols}", + howpublished="RFC 3470 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3470", + pages="1--28", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3470.txt", + key="RFC 3470", + abstract={The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="data, documents, structure", + doi="10.17487/RFC3470", + } + +@misc{rfc3471, + author="L. {Berger (Ed.)}", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description}", + howpublished="RFC 3471 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3471", + pages="1--34", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4201, 4328, 4872, 6002, 6003, 6205, 7074, 7699, 8359", +url="https://www.rfc-editor.org/rfc/rfc3471.txt", + key="RFC 3471", + abstract={This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]}, + keywords="mpls, sonet/sdh", + doi="10.17487/RFC3471", + } + +@misc{rfc3472, + author="P. {Ashwood-Smith (Ed.)} and L. {Berger (Ed.)}", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions}", + howpublished="RFC 3472 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3472", + pages="1--23", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3468, 4201", +url="https://www.rfc-editor.org/rfc/rfc3472.txt", + key="RFC 3472", + abstract={This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]}, + keywords="mpls, sonet/sdh", + doi="10.17487/RFC3472", + } + +@misc{rfc3473, + author="L. {Berger (Ed.)}", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions}", + howpublished="RFC 3473 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3473", + pages="1--42", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4003, 4201, 4420, 4783, 4874, 4873, 4974, 5063, 5151, 5420, 6002, 6003, 6780, 8359", +url="https://www.rfc-editor.org/rfc/rfc3473.txt", + key="RFC 3473", + abstract={This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]}, + keywords="mpls, sonet/sdh", + doi="10.17487/RFC3473", + } + +@misc{rfc3474, + author="Z. Lin and D. Pendarakis", + 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)}", + howpublished="RFC 3474 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3474", + pages="1--25", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3474.txt", + key="RFC 3474", + abstract={The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.}, + keywords="sonet, sdh", + doi="10.17487/RFC3474", + } + +@misc{rfc3475, + author="O. Aboul-Magd", + title="{Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)}", + howpublished="RFC 3475 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3475", + pages="1--13", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3468", +url="https://www.rfc-editor.org/rfc/rfc3475.txt", + key="RFC 3475", + abstract={Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community.}, + keywords="label switching protocol, itu-t", + doi="10.17487/RFC3475", + } + +@misc{rfc3476, + author="B. Rajagopalan", + 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}", + howpublished="RFC 3476 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3476", + pages="1--11", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 3468", +url="https://www.rfc-editor.org/rfc/rfc3476.txt", + key="RFC 3476", + abstract={The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community.}, + keywords="oif, optical interworking forum, uni, user network interface", + doi="10.17487/RFC3476", + } + +@misc{rfc3477, + author="K. Kompella and Y. Rekhter", + title="{Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)}", + howpublished="RFC 3477 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3477", + pages="1--9", + year=2003, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6107", +url="https://www.rfc-editor.org/rfc/rfc3477.txt", + key="RFC 3477", + abstract={Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]}, + keywords="mpls-te, traffic engineering", + doi="10.17487/RFC3477", + } + +@misc{rfc3478, + author="M. Leelanivas and Y. Rekhter and R. Aggarwal", + title="{Graceful Restart Mechanism for Label Distribution Protocol}", + howpublished="RFC 3478 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3478", + pages="1--12", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3478.txt", + key="RFC 3478", + abstract={This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the me chanism 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]}, + keywords="ldp, mpls", + doi="10.17487/RFC3478", + } + +@misc{rfc3479, + author="A. {Farrel (Ed.)}", + title="{Fault Tolerance for the Label Distribution Protocol (LDP)}", + howpublished="RFC 3479 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3479", + pages="1--52", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3479.txt", + key="RFC 3479", + abstract={Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, ``LDP Specification'', that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, ``Constraint-Based LSP Setup Using LDP'' (CR-LDP). [STANDARDS-TRACK]}, + keywords="mpls, multiprotocol label switching, cr-ldp, high availability restart", + doi="10.17487/RFC3479", + } + +@misc{rfc3480, + author="K. Kompella and Y. Rekhter and A. Kullberg", + title="{Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)}", + howpublished="RFC 3480 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3480", + pages="1--8", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3480.txt", + key="RFC 3480", + abstract={Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS-TRACK]}, + keywords="mpls, multiprotocol label switching, traffic engineering, mpls-te", + doi="10.17487/RFC3480", + } + +@misc{rfc3481, + author="H. {Inamura (Ed.)} and G. {Montenegro (Ed.)} and R. Ludwig and A. Gurtov and F. Khafizov", + title="{TCP over Second (2.5G) and Third (3G) Generation Wireless Networks}", + howpublished="RFC 3481 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3481", + pages="1--26", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3481.txt", + key="RFC 3481", + abstract={This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="paths, algorithm stacks", + doi="10.17487/RFC3481", + } + +@misc{rfc3482, + author="M. Foster and T. McGarry and J. Yu", + title="{Number Portability in the Global Switched Telephone Network (GSTN): An Overview}", + howpublished="RFC 3482 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3482", + pages="1--30", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3482.txt", + key="RFC 3482", + abstract={This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community.}, + keywords="e.164, telephony routing", + doi="10.17487/RFC3482", + } + +@misc{rfc3483, + author="D. Rawlins and A. Kulkarni and M. Bokaemper and K. Chan", + title="{Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)}", + howpublished="RFC 3483 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3483", + pages="1--10", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3483.txt", + key="RFC 3483", + abstract={Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community.}, + keywords="accounting, policy decision, point, bdp", + doi="10.17487/RFC3483", + } + +@misc{rfc3484, + author="R. Draves", + title="{Default Address Selection for Internet Protocol version 6 (IPv6)}", + howpublished="RFC 3484 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3484", + pages="1--24", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6724", +url="https://www.rfc-editor.org/rfc/rfc3484.txt", + key="RFC 3484", + abstract={This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS-TRACK]}, + keywords="source, address destination", + doi="10.17487/RFC3484", + } + +@misc{rfc3485, + author="M. Garcia-Martin and C. Bormann and J. Ott and R. Price and A. B. Roach", + title="{The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)}", + howpublished="RFC 3485 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3485", + pages="1--30", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4896", +url="https://www.rfc-editor.org/rfc/rfc3485.txt", + key="RFC 3485", + abstract={The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS-TRACK]}, + keywords="algorithm", + doi="10.17487/RFC3485", + } + +@misc{rfc3486, + author="G. Camarillo", + title="{Compressing the Session Initiation Protocol (SIP)}", + howpublished="RFC 3486 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3486", + pages="1--12", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5049", +url="https://www.rfc-editor.org/rfc/rfc3486.txt", + key="RFC 3486", + abstract={This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3486", + } + +@misc{rfc3487, + author="H. Schulzrinne", + title="{Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3487 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3487", + pages="1--17", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3487.txt", + key="RFC 3487", + abstract={This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community.}, + keywords="circuit switched network resources, end system resources, proxy resources, emergency preparedness communications", + doi="10.17487/RFC3487", + } + +@misc{rfc3488, + author="I. Wu and T. Eckert", + title="{Cisco Systems Router-port Group Management Protocol (RGMP)}", + howpublished="RFC 3488 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3488", + pages="1--17", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3488.txt", + key="RFC 3488", + abstract={This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community.}, + keywords="multicast, switches packet", + doi="10.17487/RFC3488", + } + +@misc{rfc3489, + author="J. Rosenberg and J. Weinberger and C. Huitema and R. Mahy", + title="{STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)}", + howpublished="RFC 3489 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3489", + pages="1--47", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5389", +url="https://www.rfc-editor.org/rfc/rfc3489.txt", + key="RFC 3489", + abstract={Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS-TRACK]}, + keywords="lightweight, applications, firewalls", + doi="10.17487/RFC3489", + } + +@misc{rfc3490, + author="P. Faltstrom and P. Hoffman and A. Costello", + title="{Internationalizing Domain Names in Applications (IDNA)}", + howpublished="RFC 3490 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3490", + pages="1--22", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5890, 5891", +url="https://www.rfc-editor.org/rfc/rfc3490.txt", + key="RFC 3490", + abstract={Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]}, + keywords="idn, ascii, characters", + doi="10.17487/RFC3490", + } + +@misc{rfc3491, + author="P. Hoffman and M. Blanchet", + title="{Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)}", + howpublished="RFC 3491 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3491", + pages="1--7", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5891", +url="https://www.rfc-editor.org/rfc/rfc3491.txt", + key="RFC 3491", + abstract={This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS-TRACK]}, + keywords="idna, applications", + doi="10.17487/RFC3491", + } + +@misc{rfc3492, + author="A. Costello", + title="{Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)}", + howpublished="RFC 3492 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3492", + pages="1--35", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5891", +url="https://www.rfc-editor.org/rfc/rfc3492.txt", + key="RFC 3492", + abstract={Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]}, + keywords="syntax, string host label", + doi="10.17487/RFC3492", + } + +@misc{rfc3493, + author="R. Gilligan and S. Thomson and J. Bound and J. McCann and W. Stevens", + title="{Basic Socket Interface Extensions for IPv6}", + howpublished="RFC 3493 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3493", + pages="1--39", + year=2003, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3493.txt", + key="RFC 3493", + abstract={The de facto standard Application Program Interface (API) for TCP/IP applications is the ``sockets'' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.}, + keywords="internet, protocol, api, application, program, interface, tcp, transmission control", + doi="10.17487/RFC3493", + } + +@misc{rfc3494, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status}", + howpublished="RFC 3494 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3494", + pages="1--5", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3494.txt", + key="RFC 3494", + abstract={This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community.}, + keywords="DAP, interactive, access, X.500, LDAP, lightweight directory protocol, STR-REP, directory names, representing names", + doi="10.17487/RFC3494", + } + +@misc{rfc3495, + author="B. Beser and P. {Duffy (Ed.)}", + title="{Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration}", + howpublished="RFC 3495 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3495", + pages="1--13", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3495.txt", + key="RFC 3495", + abstract={This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS-TRACK]}, + keywords="packetcable media terminal adapter, mta", + doi="10.17487/RFC3495", + } + +@misc{rfc3496, + author="A. G. Malis and T. Hsiao", + title="{Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering}", + howpublished="RFC 3496 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3496", + pages="1--6", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3496.txt", + key="RFC 3496", + abstract={This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.}, + keywords="diff-serv, diffserv, rsvp-te, resource reservation protocol", + doi="10.17487/RFC3496", + } + +@misc{rfc3497, + author="L. Gharai and C. Perkins and G. Goncher and A. Mankin", + title="{RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video}", + howpublished="RFC 3497 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3497", + pages="1--12", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3497.txt", + key="RFC 3497", + abstract={This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS-TRACK]}, + keywords="real-time transport protocol, hdtv, high definition television", + doi="10.17487/RFC3497", + } + +@misc{rfc3498, + author="J. Kuhfeld and J. Johnson and M. Thatcher", + title="{Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures}", + howpublished="RFC 3498 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3498", + pages="1--43", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3498.txt", + key="RFC 3498", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS-TRACK]}, + keywords="mib, management information base, tcp/ip transmission control protocol, internet protocol", + doi="10.17487/RFC3498", + } + +@misc{rfc3499, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 3400-3499}", + howpublished="RFC 3499 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3499", + pages="1--38", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3499.txt", + key="RFC 3499", + doi="10.17487/RFC3499", + } + +@misc{rfc3501, + author="M. Crispin", + title="{INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1}", + howpublished="RFC 3501 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3501", + pages="1--108", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4466, 4469, 4551, 5032, 5182, 5738, 6186, 6858, 7817, 8314, 8437, 8474", +url="https://www.rfc-editor.org/rfc/rfc3501.txt", + key="RFC 3501", + abstract={The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting m ail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]}, + keywords="IMAPv4, imap, imapv4rev1", + doi="10.17487/RFC3501", + } + +@misc{rfc3502, + author="M. Crispin", + title="{Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension}", + howpublished="RFC 3502 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3502", + pages="1--7", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4466, 4469", +url="https://www.rfc-editor.org/rfc/rfc3502.txt", + key="RFC 3502", + abstract={This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of ``MULTIAPPEND''. [STANDARDS-TRACK]}, + keywords="IMAPv4, imap, imapv4rev1", + doi="10.17487/RFC3502", + } + +@misc{rfc3503, + author="A. Melnikov", + title="{Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)}", + howpublished="RFC 3503 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3503", + pages="1--9", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3503.txt", + key="RFC 3503", + abstract={The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment. This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS-TRACK]}, + keywords="mua, mail user agent, imap4", + doi="10.17487/RFC3503", + } + +@misc{rfc3504, + author="D. Eastlake", + title="{Internet Open Trading Protocol (IOTP) Version 1, Errata}", + howpublished="RFC 3504 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3504", + pages="1--6", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3504.txt", + key="RFC 3504", + abstract={Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted. This informational document lists these errors and provides corrections for them. This memo provides information for the Internet community.}, + keywords="commerce, payment, system, merchant, system, xml, extensible, markup, language, security", + doi="10.17487/RFC3504", + } + +@misc{rfc3505, + author="D. Eastlake", + title="{Electronic Commerce Modeling Language (ECML): Version 2 Requirements}", + howpublished="RFC 3505 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3505", + pages="1--8", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3505.txt", + key="RFC 3505", + abstract={This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing. This memo provides information for the Internet community.}, + keywords="xml, extensible markup language", + doi="10.17487/RFC3505", + } + +@misc{rfc3506, + author="K. Fujimura and D. Eastlake", + title="{Requirements and Design for Voucher Trading System (VTS)}", + howpublished="RFC 3506 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3506", + pages="1--15", + year=2003, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3506.txt", + key="RFC 3506", + abstract={Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a ``voucher'', which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described. This memo provides information for the Internet community.}, + keywords="generic voucher language, gvl", + doi="10.17487/RFC3506", + } + +@misc{rfc3507, + author="J. Elson and A. Cerpa", + title="{Internet Content Adaptation Protocol (ICAP)}", + howpublished="RFC 3507 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3507", + pages="1--49", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3507.txt", + key="RFC 3507", + abstract={ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a ``remote procedure call'' on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing (``adaptation''). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. This memo provides information for the Internet community.}, + keywords="http, hyper-text markup protocol, request, response, client server", + doi="10.17487/RFC3507", + } + +@misc{rfc3508, + author="O. Levin", + title="{H.323 Uniform Resource Locator (URL) Scheme Registration}", + howpublished="RFC 3508 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3508", + pages="1--6", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3508.txt", + key="RFC 3508", + abstract={ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.}, + keywords="itu-t, packet networks", + doi="10.17487/RFC3508", + } + +@misc{rfc3509, + author="A. Zinin and A. Lindem and D. Yeung", + title="{Alternative Implementations of OSPF Area Border Routers}", + howpublished="RFC 3509 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3509", + pages="1--12", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3509.txt", + key="RFC 3509", + abstract={Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. This memo provides information for the Internet community.}, + keywords="traffic, backbone", + doi="10.17487/RFC3509", + } + +@misc{rfc3510, + author="R. Herriot and I. McDonald", + title="{Internet Printing Protocol/1.1: IPP URL Scheme}", + howpublished="RFC 3510 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3510", + pages="1--16", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3510.txt", + key="RFC 3510", + abstract={This memo defines the ``ipp'' URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, ``IPP URL Scheme'', of RFC 2910. An ``ipp'' URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS-TRACK]}, + keywords="IPP-E-T, IPP, application, media-type, media, type", + doi="10.17487/RFC3510", + } + +@misc{rfc3511, + author="B. Hickman and D. Newman and S. Tadjudin and T. Martin", + title="{Benchmarking Methodology for Firewall Performance}", + howpublished="RFC 3511 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3511", + pages="1--34", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3511.txt", + key="RFC 3511", + abstract={This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.}, + keywords="client server, traffic, authentication, web caching", + doi="10.17487/RFC3511", + } + +@misc{rfc3512, + author="M. MacFaden and D. Partain and J. Saperia and W. Tackabury", + title="{Configuring Networks and Devices with Simple Network Management Protocol (SNMP)}", + howpublished="RFC 3512 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3512", + pages="1--83", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3512.txt", + key="RFC 3512", + abstract={This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This memo provides information for the Internet community.}, + keywords="internet standard framework", + doi="10.17487/RFC3512", + } + +@misc{rfc3513, + author="R. Hinden and S. Deering", + title="{Internet Protocol Version 6 (IPv6) Addressing Architecture}", + howpublished="RFC 3513 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3513", + pages="1--26", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4291", +url="https://www.rfc-editor.org/rfc/rfc3513.txt", + key="RFC 3513", + abstract={This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK]}, + keywords="internet, protocol, unicast, anycast, multicast, node", + doi="10.17487/RFC3513", + } + +@misc{rfc3514, + author="S. Bellovin", + title="{The Security Flag in the IPv4 Header}", + howpublished="RFC 3514 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3514", + pages="1--6", + year=2003, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3514.txt", + key="RFC 3514", + abstract={Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.}, + keywords="evil, evil bit", + doi="10.17487/RFC3514", + } + +@misc{rfc3515, + author="R. Sparks", + title="{The Session Initiation Protocol (SIP) Refer Method}", + howpublished="RFC 3515 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3515", + pages="1--23", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7647, 8217", +url="https://www.rfc-editor.org/rfc/rfc3515.txt", + key="RFC 3515", + abstract={This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]}, + keywords="resource request, call transfer", + doi="10.17487/RFC3515", + } + +@misc{rfc3516, + author="L. Nerenberg", + title="{IMAP4 Binary Content Extension}", + howpublished="RFC 3516 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3516", + pages="1--8", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4466", +url="https://www.rfc-editor.org/rfc/rfc3516.txt", + key="RFC 3516", + abstract={This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS-TRACK]}, + keywords="internet message acess procotol", + doi="10.17487/RFC3516", + } + +@misc{rfc3517, + author="E. Blanton and M. Allman and K. Fall and L. Wang", + title="{A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP}", + howpublished="RFC 3517 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3517", + pages="1--13", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6675", +url="https://www.rfc-editor.org/rfc/rfc3517.txt", + key="RFC 3517", + abstract={This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS-TRACK]}, + keywords="transmission control protocol, retransmission, congestion control", + doi="10.17487/RFC3517", + } + +@misc{rfc3518, + author="M. Higashiyama and F. Baker and T. Liao", + title="{Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)}", + howpublished="RFC 3518 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3518", + pages="1--40", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3518.txt", + key="RFC 3518", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE 802.1D- 1993 MAC Bridge. This document extends that specification by improving support for bridge control packets. [STANDARDS-TRACK]}, + keywords="PPP-BCP, point-to-point, datagrams, network", + doi="10.17487/RFC3518", + } + +@misc{rfc3519, + author="H. Levkowetz and S. Vaarala", + title="{Mobile IP Traversal of Network Address Translation (NAT) Devices}", + howpublished="RFC 3519 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3519", + pages="1--34", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3519.txt", + key="RFC 3519", + abstract={Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS-TRACK]}, + keywords="Internet Protocol, datagram, traffic, Mobile IP, NAT, NAPT, traversal, tunnelling, tunneling, UDP, private address space, keepalives, port 434, MIP, MIPv4, network address translation", + doi="10.17487/RFC3519", + } + +@misc{rfc3520, + author="L-N. Hamer and B. Gage and B. Kosinski and H. Shieh", + title="{Session Authorization Policy Element}", + howpublished="RFC 3520 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3520", + pages="1--30", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3520.txt", + key="RFC 3520", + abstract={This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scen arios. [STANDARDS-TRACK]}, + keywords="admission control, resource reservation", + doi="10.17487/RFC3520", + } + +@misc{rfc3521, + author="L-N. Hamer and B. Gage and H. Shieh", + title="{Framework for Session Set-up with Media Authorization}", + howpublished="RFC 3521 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3521", + pages="1--25", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3521.txt", + key="RFC 3521", + abstract={Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in- line with the media streams requested (and authorized) for the session. This memo provides information for the Internet community.}, + keywords="qos, quality of service, streams, linkage, policy control, admission, theft service, resource reservation, token", + doi="10.17487/RFC3521", + } + +@misc{rfc3522, + author="R. Ludwig and M. Meyer", + title="{The Eifel Detection Algorithm for TCP}", + howpublished="RFC 3522 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3522", + pages="1--14", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3522.txt", + key="RFC 3522", + abstract={The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.}, + keywords="transmission control protocol, loss recovery, timestamps", + doi="10.17487/RFC3522", + } + +@misc{rfc3523, + author="J. Polk", + title="{Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology}", + howpublished="RFC 3523 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3523", + pages="1--6", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3523.txt", + key="RFC 3523", + abstract={This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This memo provides information for the Internet community.}, + keywords="naming convetions, phone", + doi="10.17487/RFC3523", + } + +@misc{rfc3524, + author="G. Camarillo and A. Monrad", + title="{Mapping of Media Streams to Resource Reservation Flows}", + howpublished="RFC 3524 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3524", + pages="1--6", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3524.txt", + key="RFC 3524", + abstract={This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new ``semantics'' attribute called Single Reservation Flow (SRF). [STANDARDS-TRACK]}, + keywords="sdp, session description protocol, srf, single", + doi="10.17487/RFC3524", + } + +@misc{rfc3525, + author="C. {Groves (Ed.)} and M. {Pantaleo (Ed.)} and T. {Anderson (Ed.)} and T. {Taylor (Ed.)}", + title="{Gateway Control Protocol Version 1}", + howpublished="RFC 3525 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3525", + pages="1--213", + year=2003, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5125", +url="https://www.rfc-editor.org/rfc/rfc3525.txt", + key="RFC 3525", + abstract={This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at https://www.it u.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS-TRACK]}, + keywords="MEGACO, H.248, media, gateway, control", + doi="10.17487/RFC3525", + } + +@misc{rfc3526, + author="T. Kivinen and M. Kojo", + title="{More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)}", + howpublished="RFC 3526 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3526", + pages="1--10", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3526.txt", + key="RFC 3526", + abstract={This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK]}, + keywords="bit groups", + doi="10.17487/RFC3526", + } + +@misc{rfc3527, + author="K. Kinnear and M. Stapp and R. Johnson and J. Kumarasamy", + title="{Link Selection sub-option for the Relay Agent Information Option for DHCPv4}", + howpublished="RFC 3527 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3527", + pages="1--9", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3527.txt", + key="RFC 3527", + abstract={This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS-TRACK]}, + keywords="dynamic host configuration protocol", + doi="10.17487/RFC3527", + } + +@misc{rfc3528, + author="W. Zhao and H. Schulzrinne and E. Guttman", + title="{Mesh-enhanced Service Location Protocol (mSLP)}", + howpublished="RFC 3528 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3528", + pages="1--15", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3528.txt", + key="RFC 3528", + abstract={This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti- entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. This memo defines an Experimental Protocol for the Internet community.}, + keywords="da, directory agent, slpda, service agent, sa, slpv2", + doi="10.17487/RFC3528", + } + +@misc{rfc3529, + author="W. Harold", + title="{Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)}", + howpublished="RFC 3529 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3529", + pages="1--15", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3529.txt", + key="RFC 3529", + abstract={Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community.}, + keywords="format, messages, clients, servers", + doi="10.17487/RFC3529", + } + +@misc{rfc3530, + author="S. Shepler and B. Callaghan and D. Robinson and R. Thurlow and C. Beame and M. Eisler and D. Noveck", + title="{Network File System (NFS) version 4 Protocol}", + howpublished="RFC 3530 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3530", + pages="1--275", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7530", +url="https://www.rfc-editor.org/rfc/rfc3530.txt", + key="RFC 3530", + abstract={The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS-TRACK]}, + keywords="NFSv4, network, file, system", + doi="10.17487/RFC3530", + } + +@misc{rfc3531, + author="M. Blanchet", + title="{A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block}", + howpublished="RFC 3531 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3531", + pages="1--7", + year=2003, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3531.txt", + key="RFC 3531", + abstract={This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. This memo provides information for the Internet community.}, + keywords="address plan, addressing, range, space, internet protocol", + doi="10.17487/RFC3531", + } + +@misc{rfc3532, + author="T. Anderson and J. Buerkle", + title="{Requirements for the Dynamic Partitioning of Switching Elements}", + howpublished="RFC 3532 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3532", + pages="1--11", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3532.txt", + key="RFC 3532", + abstract={This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. This memo provides information for the Internet community.}, + keywords="atm, asynchronous transfer mode", + doi="10.17487/RFC3532", + } + +@misc{rfc3533, + author="S. Pfeiffer", + title="{The Ogg Encapsulation Format Version 0}", + howpublished="RFC 3533 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3533", + pages="1--15", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3533.txt", + key="RFC 3533", + abstract={This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community.}, + keywords="bitstream, media streams, video, audio, xiph.org, multimedia, media interleading format, video bitstream packaging, audio bitstream packaging, free encapsulation format, stream based storage of codec data, framed bitstream", + doi="10.17487/RFC3533", + } + +@misc{rfc3534, + author="L. Walleij", + title="{The application/ogg Media Type}", + howpublished="RFC 3534 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3534", + pages="1--6", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5334", +url="https://www.rfc-editor.org/rfc/rfc3534.txt", + key="RFC 3534", + abstract={The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS-TRACK]}, + keywords="mime, multipurpose internet mail extenstions", + doi="10.17487/RFC3534", + } + +@misc{rfc3535, + author="J. Schoenwaelder", + title="{Overview of the 2002 IAB Network Management Workshop}", + howpublished="RFC 3535 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3535", + pages="1--20", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3535.txt", + key="RFC 3535", + abstract={This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community.}, + keywords="Internet Architecture Board", + doi="10.17487/RFC3535", + } + +@misc{rfc3536, + author="P. Hoffman", + title="{Terminology Used in Internationalization in the IETF}", + howpublished="RFC 3536 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3536", + pages="1--30", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6365", +url="https://www.rfc-editor.org/rfc/rfc3536.txt", + key="RFC 3536", + abstract={This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community.}, + keywords="internet engineering task force", + doi="10.17487/RFC3536", + } + +@misc{rfc3537, + author="J. Schaad and R. Housley", + title="{Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key}", + howpublished="RFC 3537 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3537", + pages="1--9", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3537.txt", + key="RFC 3537", + abstract={This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD]}, + keywords="", + doi="10.17487/RFC3537", + } + +@misc{rfc3538, + author="Y. Kawatsura", + title="{Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)}", + howpublished="RFC 3538 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3538", + pages="1--56", + year=2003, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3538.txt", + key="RFC 3538", + abstract={This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. This memo provides information for the Internet community.}, + keywords="payment, input, output, parameter", + doi="10.17487/RFC3538", + } + +@misc{rfc3539, + author="B. Aboba and J. Wood", + title="{Authentication, Authorization and Accounting (AAA) Transport Profile}", + howpublished="RFC 3539 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3539", + pages="1--41", + year=2003, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3539.txt", + key="RFC 3539", + abstract={This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3539", + } + +@misc{rfc3540, + author="N. Spring and D. Wetherall and D. Ely", + title="{Robust Explicit Congestion Notification (ECN) Signaling with Nonces}", + howpublished="RFC 3540 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3540", + pages="1--13", + year=2003, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3540.txt", + key="RFC 3540", + abstract={This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community.}, + keywords="congestion control, tcp, traffic control protocol", + doi="10.17487/RFC3540", + } + +@misc{rfc3541, + author="A. Walsh", + title="{A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)}", + howpublished="RFC 3541 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3541", + pages="1--6", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3541.txt", + key="RFC 3541", + abstract={This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. This memo provides information for the Internet community.}, + keywords="virtual reality monitoring language, vrml, extensible markup language, x3d, xml, dtd, document type definition", + doi="10.17487/RFC3541", + } + +@misc{rfc3542, + author="W. Stevens and M. Thomas and E. Nordmark and T. Jinmei", + title="{Advanced Sockets Application Program Interface (API) for IPv6}", + howpublished="RFC 3542 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3542", + pages="1--77", + year=2003, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3542.txt", + key="RFC 3542", + abstract={This document provides sockets Application Program Interface (API) to support ``advanced'' IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the ``r'' commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community.}, + keywords="application, program, interface", + doi="10.17487/RFC3542", + } + +@misc{rfc3543, + author="S. Glass and M. Chandra", + title="{Registration Revocation in Mobile IPv4}", + howpublished="RFC 3543 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3543", + pages="1--33", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3543.txt", + key="RFC 3543", + abstract={This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS-TRACK]}, + keywords="internet protocol", + doi="10.17487/RFC3543", + } + +@misc{rfc3544, + author="T. Koren and S. Casner and C. Bormann", + title="{IP Header Compression over PPP}", + howpublished="RFC 3544 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3544", + pages="1--14", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3544.txt", + key="RFC 3544", + abstract={This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS-TRACK]}, + keywords="IPCOM-PPP, internet, protocol, point-to-point, datagrams", + doi="10.17487/RFC3544", + } + +@misc{rfc3545, + author="T. Koren and S. Casner and J. Geevarghese and B. Thompson and P. Ruddy", + title="{Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering}", + howpublished="RFC 3545 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3545", + pages="1--22", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3545.txt", + key="RFC 3545", + abstract={This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS-TRACK]}, + keywords="point to point, header", + doi="10.17487/RFC3545", + } + +@misc{rfc3546, + author="S. Blake-Wilson and M. Nystrom and D. Hopwood and J. Mikkelsen and T. Wright", + title="{Transport Layer Security (TLS) Extensions}", + howpublished="RFC 3546 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3546", + pages="1--29", + year=2003, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4366", +url="https://www.rfc-editor.org/rfc/rfc3546.txt", + key="RFC 3546", + abstract={This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]}, + keywords="transport, protocol, layer, authentication, privacy", + doi="10.17487/RFC3546", + } + +@misc{rfc3547, + author="M. Baugher and B. Weis and T. Hardjono and H. Harney", + title="{The Group Domain of Interpretation}", + howpublished="RFC 3547 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3547", + pages="1--48", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6407", +url="https://www.rfc-editor.org/rfc/rfc3547.txt", + key="RFC 3547", + abstract={This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS-TRACK]}, + keywords="isamkp, doi, key management, security, encryption", + doi="10.17487/RFC3547", + } + +@misc{rfc3548, + author="S. {Josefsson (Ed.)}", + title="{The Base16, Base32, and Base64 Data Encodings}", + howpublished="RFC 3548 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3548", + pages="1--13", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4648", +url="https://www.rfc-editor.org/rfc/rfc3548.txt", + key="RFC 3548", + abstract={This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community.}, + keywords="schemes, data, line-feeds, alphabets, base encoding, hex", + doi="10.17487/RFC3548", + } + +@misc{rfc3549, + author="J. Salim and H. Khosravi and A. Kleen and A. Kuznetsov", + title="{Linux Netlink as an IP Services Protocol}", + howpublished="RFC 3549 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3549", + pages="1--33", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3549.txt", + key="RFC 3549", + abstract={This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.}, + keywords="internet protocol messaging system", + doi="10.17487/RFC3549", + } + +@misc{rfc3550, + author="H. Schulzrinne and S. Casner and R. Frederick and V. Jacobson", + title="{RTP: A Transport Protocol for Real-Time Applications}", + howpublished="RFC 3550 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3550", + pages="1--104", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5506, 5761, 6051, 6222, 7022, 7160, 7164, 8083, 8108", +url="https://www.rfc-editor.org/rfc/rfc3550.txt", + key="RFC 3550", + abstract={This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]}, + keywords="RTP, end-to-end, network, audio, video, RTCP", + doi="10.17487/RFC3550", + } + +@misc{rfc3551, + author="H. Schulzrinne and S. Casner", + title="{RTP Profile for Audio and Video Conferences with Minimal Control}", + howpublished="RFC 3551 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3551", + pages="1--44", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5761, 7007", +url="https://www.rfc-editor.org/rfc/rfc3551.txt", + key="RFC 3551", + abstract={This document describes a profile called ``RTP/AVP'' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]}, + keywords="RTP-AV, end-to-end, network, conference", + doi="10.17487/RFC3551", + } + +@misc{rfc3552, + author="E. Rescorla and B. Korver", + title="{Guidelines for Writing RFC Text on Security Considerations}", + howpublished="RFC 3552 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3552", + pages="1--44", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3552.txt", + key="RFC 3552", + abstract={All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Request for Comment", + doi="10.17487/RFC3552", + } + +@misc{rfc3553, + author="M. Mealling and L. Masinter and T. Hardie and G. Klyne", + title="{An IETF URN Sub-namespace for Registered Protocol Parameters}", + howpublished="RFC 3553 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3553", + pages="1--8", + year=2003, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3553.txt", + key="RFC 3553", + abstract={This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="syntax, uniform resource names", + doi="10.17487/RFC3553", + } + +@misc{rfc3554, + author="S. Bellovin and J. Ioannidis and A. Keromytis and R. Stewart", + title="{On the Use of Stream Control Transmission Protocol (SCTP) with IPsec}", + howpublished="RFC 3554 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3554", + pages="1--9", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3554.txt", + key="RFC 3554", + abstract={This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS-TRACK]}, + keywords="ike, internet key exchange, security", + doi="10.17487/RFC3554", + } + +@misc{rfc3555, + author="S. Casner and P. Hoschka", + title="{MIME Type Registration of RTP Payload Formats}", + howpublished="RFC 3555 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3555", + pages="1--45", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4855, 4856, updated by RFCs 3625, 4629", +url="https://www.rfc-editor.org/rfc/rfc3555.txt", + key="RFC 3555", + abstract={This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text- based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]}, + keywords="real time transport protocol, multipurpose internet mail extensions", + doi="10.17487/RFC3555", + } + +@misc{rfc3556, + author="S. Casner", + title="{Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth}", + howpublished="RFC 3556 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3556", + pages="1--8", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3556.txt", + key="RFC 3556", + abstract={This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]}, + keywords="real time transport protocol, real-time", + doi="10.17487/RFC3556", + } + +@misc{rfc3557, + author="Q. {Xie (Ed.)}", + title="{RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding}", + howpublished="RFC 3557 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3557", + pages="1--15", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3557.txt", + key="RFC 3557", + abstract={This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]}, + keywords="real time transport protocol, real-time, dsr", + doi="10.17487/RFC3557", + } + +@misc{rfc3558, + author="A. Li", + title="{RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)}", + howpublished="RFC 3558 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3558", + pages="1--23", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4788", +url="https://www.rfc-editor.org/rfc/rfc3558.txt", + key="RFC 3558", + abstract={This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS-TRACK]}, + keywords="real time transport protocol, real-time, bundled, interleaved", + doi="10.17487/RFC3558", + } + +@misc{rfc3559, + author="D. Thaler", + title="{Multicast Address Allocation MIB}", + howpublished="RFC 3559 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3559", + pages="1--37", + year=2003, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3559.txt", + key="RFC 3559", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. [STANDARDS-TRACK]}, + keywords="maas, management information base", + doi="10.17487/RFC3559", + } + +@misc{rfc3560, + author="R. Housley", + title="{Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 3560 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3560", + pages="1--18", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3560.txt", + key="RFC 3560", + abstract={This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK]}, + keywords="security encryption", + doi="10.17487/RFC3560", + } + +@misc{rfc3561, + author="C. Perkins and E. Belding-Royer and S. Das", + title="{Ad hoc On-Demand Distance Vector (AODV) Routing}", + howpublished="RFC 3561 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3561", + pages="1--37", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3561.txt", + key="RFC 3561", + abstract={The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as ``counting to infinity'') associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community.}, + keywords="unicast, multiple nodes", + doi="10.17487/RFC3561", + } + +@misc{rfc3562, + author="M. Leech", + title="{Key Management Considerations for the TCP MD5 Signature Option}", + howpublished="RFC 3562 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3562", + pages="1--7", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3562.txt", + key="RFC 3562", + abstract={The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community.}, + keywords="bgp, border gateway protocol, security, encryption", + doi="10.17487/RFC3562", + } + +@misc{rfc3563, + author="A. Zinin", + 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}", + howpublished="RFC 3563 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3563", + pages="1--8", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6233", +url="https://www.rfc-editor.org/rfc/rfc3563.txt", + key="RFC 3563", + abstract={This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community.}, + doi="10.17487/RFC3563", + } + +@misc{rfc3564, + author="F. Le Faucheur and W. Lai", + title="{Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering}", + howpublished="RFC 3564 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3564", + pages="1--22", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc3564.txt", + key="RFC 3564", + abstract={This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. This memo provides information for the Internet community.}, + keywords="multi-protocol label switching, bandwidth constraints model, overbooking", + doi="10.17487/RFC3564", + } + +@misc{rfc3565, + author="J. Schaad", + title="{Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 3565 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3565", + pages="1--14", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3565.txt", + key="RFC 3565", + abstract={This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]}, + keywords="security, data encoding", + doi="10.17487/RFC3565", + } + +@misc{rfc3566, + author="S. Frankel and H. Herbert", + title="{The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec}", + howpublished="RFC 3566 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3566", + pages="1--11", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3566.txt", + key="RFC 3566", + abstract={A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. [STANDARDS-TRACK]}, + keywords="authentication, hash security", + doi="10.17487/RFC3566", + } + +@misc{rfc3567, + author="T. Li and R. Atkinson", + title="{Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication}", + howpublished="RFC 3567 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3567", + pages="1--6", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5304", +url="https://www.rfc-editor.org/rfc/rfc3567.txt", + key="RFC 3567", + abstract={This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community.}, + keywords="iso, international standards organization", + doi="10.17487/RFC3567", + } + +@misc{rfc3568, + author="A. Barbir and B. Cain and R. Nair and O. Spatscheck", + title="{Known Content Network (CN) Request-Routing Mechanisms}", + howpublished="RFC 3568 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3568", + pages="1--19", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3568.txt", + key="RFC 3568", + abstract={This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community.}, + keywords="metrics, routing, redirection", + doi="10.17487/RFC3568", + } + +@misc{rfc3569, + author="S. {Bhattacharyya (Ed.)}", + title="{An Overview of Source-Specific Multicast (SSM)}", + howpublished="RFC 3569 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3569", + pages="1--14", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3569.txt", + key="RFC 3569", + abstract={The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community.}, + keywords="routing applications, deployment interoperability", + doi="10.17487/RFC3569", + } + +@misc{rfc3570, + author="P. Rzewski and M. Day and D. Gilletti", + title="{Content Internetworking (CDI) Scenarios}", + howpublished="RFC 3570 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3570", + pages="1--20", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6770", +url="https://www.rfc-editor.org/rfc/rfc3570.txt", + key="RFC 3570", + abstract={In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. This memo provides information for the Internet community.}, + keywords="production networks", + doi="10.17487/RFC3570", + } + +@misc{rfc3571, + author="D. Rawlins and A. Kulkarni and K. Ho Chan and M. Bokaemper and D. Dutt", + title="{Framework Policy Information Base for Usage Feedback}", + howpublished="RFC 3571 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3571", + pages="1--35", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3571.txt", + key="RFC 3571", + abstract={This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community.}, + keywords="pib", + doi="10.17487/RFC3571", + } + +@misc{rfc3572, + author="T. Ogura and M. Maruyama and T. Yoshida", + title="{Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)}", + howpublished="RFC 3572 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3572", + pages="1--14", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc3572.txt", + key="RFC 3572", + abstract={Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. This memo provides information for the Internet community.}, + keywords="ipv6, synchronous optical network, synchronous digital hierarchy", + doi="10.17487/RFC3572", + } + +@misc{rfc3573, + author="I. Goyret", + title="{Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)}", + howpublished="RFC 3573 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3573", + pages="1--13", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3573.txt", + key="RFC 3573", + abstract={The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS-TRACK]}, + keywords="ppp, point to point, point-to-point, pstn, public switched telephone network", + doi="10.17487/RFC3573", + } + +@misc{rfc3574, + author="J. {Soininen (Ed.)}", + title="{Transition Scenarios for 3GPP Networks}", + howpublished="RFC 3574 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3574", + pages="1--12", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3574.txt", + key="RFC 3574", + abstract={This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community.}, + keywords="third generation parnership project, packet, ipv6, ipv4, internet", + doi="10.17487/RFC3574", + } + +@misc{rfc3575, + author="B. Aboba", + title="{IANA Considerations for RADIUS (Remote Authentication Dial In User Service)}", + howpublished="RFC 3575 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3575", + pages="1--8", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6929", +url="https://www.rfc-editor.org/rfc/rfc3575.txt", + key="RFC 3575", + abstract={This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]}, + keywords="internet assigned numbers authority, encryption, NAS, Network, Access, Server", + doi="10.17487/RFC3575", + } + +@misc{rfc3576, + author="M. Chiba and G. Dommety and M. Eklund and D. Mitton and B. Aboba", + title="{Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)}", + howpublished="RFC 3576 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3576", + pages="1--30", + year=2003, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5176", +url="https://www.rfc-editor.org/rfc/rfc3576.txt", + key="RFC 3576", + abstract={This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.}, + keywords="nas, network access server", + doi="10.17487/RFC3576", + } + +@misc{rfc3577, + author="S. Waldbusser and R. Cole and C. Kalbfleisch and D. Romascanu", + title="{Introduction to the Remote Monitoring (RMON) Family of MIB Modules}", + howpublished="RFC 3577 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3577", + pages="1--31", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3577.txt", + key="RFC 3577", + abstract={The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. This memo provides information for the Internet community.}, + keywords="management information base", + doi="10.17487/RFC3577", + } + +@misc{rfc3578, + author="G. Camarillo and A. B. Roach and J. Peterson and L. Ong", + title="{Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)}", + howpublished="RFC 3578 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3578", + pages="1--13", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3578.txt", + key="RFC 3578", + abstract={This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS-TRACK]}, + keywords="pstn, public switched telephone network", + doi="10.17487/RFC3578", + } + +@misc{rfc3579, + author="B. Aboba and P. Calhoun", + title="{RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)}", + howpublished="RFC 3579 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3579", + pages="1--46", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5080", +url="https://www.rfc-editor.org/rfc/rfc3579.txt", + key="RFC 3579", + abstract={This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community.}, + keywords="RADIUS, encryption, NAS, Network, Access, Server", + doi="10.17487/RFC3579", + } + +@misc{rfc3580, + author="P. Congdon and B. Aboba and A. Smith and G. Zorn and J. Roese", + title="{IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines}", + howpublished="RFC 3580 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3580", + pages="1--30", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7268", +url="https://www.rfc-editor.org/rfc/rfc3580.txt", + key="RFC 3580", + abstract={This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.}, + keywords="AAA, authentication, authorization and accounting", + doi="10.17487/RFC3580", + } + +@misc{rfc3581, + author="J. Rosenberg and H. Schulzrinne", + title="{An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing}", + howpublished="RFC 3581 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3581", + pages="1--13", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3581.txt", + key="RFC 3581", + abstract={The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called ``rport'', that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS-TRACK]}, + keywords="report client server", + doi="10.17487/RFC3581", + } + +@misc{rfc3582, + author="J. Abley and B. Black and V. Gill", + title="{Goals for IPv6 Site-Multihoming Architectures}", + howpublished="RFC 3582 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3582", + pages="1--9", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3582.txt", + key="RFC 3582", + abstract={This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community.}, + keywords="internet protocol, multi6", + doi="10.17487/RFC3582", + } + +@misc{rfc3583, + author="H. {Chaskar (Ed.)}", + title="{Requirements of a Quality of Service (QoS) Solution for Mobile IP}", + howpublished="RFC 3583 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3583", + pages="1--10", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3583.txt", + key="RFC 3583", + abstract={Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. This memo provides information for the Internet community.}, + keywords="internet protocol, routing packets, node", + doi="10.17487/RFC3583", + } + +@misc{rfc3584, + author="R. Frye and D. Levi and S. Routhier and B. Wijnen", + title="{Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework}", + howpublished="RFC 3584 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3584", + pages="1--51", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3584.txt", + key="RFC 3584", + abstract={The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="SNMP, simple network management protocol, mib information base", + doi="10.17487/RFC3584", + } + +@misc{rfc3585, + author="J. Jason and L. Rafalow and E. Vyncke", + title="{IPsec Configuration Policy Information Model}", + howpublished="RFC 3585 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3585", + pages="1--88", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3585.txt", + key="RFC 3585", + abstract={This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task- specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS-TRACK]}, + keywords="ike, internet key exchange protocol, core, pcim", + doi="10.17487/RFC3585", + } + +@misc{rfc3586, + author="M. Blaze and A. Keromytis and M. Richardson and L. Sanchez", + title="{IP Security Policy (IPSP) Requirements}", + howpublished="RFC 3586 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3586", + pages="1--10", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3586.txt", + key="RFC 3586", + abstract={This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements. [STANDARDS-TRACK]}, + keywords="data integrity, authentication, host network", + doi="10.17487/RFC3586", + } + +@misc{rfc3587, + author="R. Hinden and S. Deering and E. Nordmark", + title="{IPv6 Global Unicast Address Format}", + howpublished="RFC 3587 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3587", + pages="1--5", + year=2003, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3587.txt", + key="RFC 3587", + abstract={This document obsoletes RFC 2374, ``An IPv6 Aggregatable Global Unicast Address Format''. It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.}, + keywords="internet, protocol, architecture, routing", + doi="10.17487/RFC3587", + } + +@misc{rfc3588, + author="P. Calhoun and J. Loughney and E. Guttman and G. Zorn and J. Arkko", + title="{Diameter Base Protocol}", + howpublished="RFC 3588 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3588", + pages="1--147", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6733, updated by RFCs 5729, 5719, 6408", +url="https://www.rfc-editor.org/rfc/rfc3588.txt", + key="RFC 3588", + abstract={The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization \& 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]}, + keywords="aaa, authentication authorization accounting, ip mobility", + doi="10.17487/RFC3588", + } + +@misc{rfc3589, + author="J. Loughney", + title="{Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5}", + howpublished="RFC 3589 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3589", + pages="1--5", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3589.txt", + key="RFC 3589", + abstract={This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community.}, + keywords="iana, allocation", + doi="10.17487/RFC3589", + } + +@misc{rfc3590, + author="B. Haberman", + title="{Source Address Selection for the Multicast Listener Discovery (MLD) Protocol}", + howpublished="RFC 3590 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3590", + pages="1--6", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3590.txt", + key="RFC 3590", + abstract={It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS-TRACK]}, + keywords="MLD-IPv6, internet protocol, routher, packets", + doi="10.17487/RFC3590", + } + +@misc{rfc3591, + author="H-K. Lam and M. Stewart and A. Huynh", + title="{Definitions of Managed Objects for the Optical Interface Type}", + howpublished="RFC 3591 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3591", + pages="1--174", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3591.txt", + key="RFC 3591", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS-TRACK]}, + keywords="management information base, mib, snmp, simple network management protocol, otn, optical transport network, itu-t, performance monitoring, configuration, dwdm, optical tranmission session, optical multiplex section, optical channel, otuk, odukt, oduk", + doi="10.17487/RFC3591", + } + +@misc{rfc3592, + author="K. Tesink", + title="{Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type}", + howpublished="RFC 3592 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3592", + pages="1--73", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3592.txt", + key="RFC 3592", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]}, + keywords="MIB, Management, SNMP", + doi="10.17487/RFC3592", + } + +@misc{rfc3593, + author="K. {Tesink (Ed.)}", + title="{Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals}", + howpublished="RFC 3593 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3593", + pages="1--10", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3593.txt", + key="RFC 3593", + abstract={This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]}, + keywords="management, information, base, data", + doi="10.17487/RFC3593", + } + +@misc{rfc3594, + author="P. Duffy", + title="{PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option}", + howpublished="RFC 3594 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3594", + pages="1--7", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3594.txt", + key="RFC 3594", + abstract={This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS-TRACK]}, + keywords="dynamic host configuration protocol", + doi="10.17487/RFC3594", + } + +@misc{rfc3595, + author="B. Wijnen", + title="{Textual Conventions for IPv6 Flow Label}", + howpublished="RFC 3595 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3595", + pages="1--6", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3595.txt", + key="RFC 3595", + abstract={This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]}, + keywords="mib, management information base", + doi="10.17487/RFC3595", + } + +@misc{rfc3596, + author="S. Thomson and C. Huitema and V. Ksinant and M. Souissi", + title="{DNS Extensions to Support IP Version 6}", + howpublished="RFC 3596 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3596", + pages="1--8", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3596.txt", + key="RFC 3596", + abstract={This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]}, + keywords="internet protocol, domain name system, DNS, zone", + doi="10.17487/RFC3596", + } + +@misc{rfc3597, + author="A. Gustafsson", + title="{Handling of Unknown DNS Resource Record (RR) Types}", + howpublished="RFC 3597 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3597", + pages="1--8", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4033, 4034, 4035, 5395, 6195, 6895", +url="https://www.rfc-editor.org/rfc/rfc3597.txt", + key="RFC 3597", + abstract={Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]}, + keywords="domain name system, name server software, compression, transparency", + doi="10.17487/RFC3597", + } + +@misc{rfc3598, + author="K. Murchison", + title="{Sieve Email Filtering -- Subaddress Extension}", + howpublished="RFC 3598 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3598", + pages="1--6", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5233", +url="https://www.rfc-editor.org/rfc/rfc3598.txt", + key="RFC 3598", + abstract={On email systems that allow for ``subaddressing'' or ``detailed addressing'' (e.g., ``ken+sieve(a)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]}, + keywords="users, detailed addressing language, address, part, test, detail, filter, mailbox", + doi="10.17487/RFC3598", + } + +@misc{rfc3599, + author="S. Ginoza", + title="{Request for Comments Summary RFC Numbers 3500-3599}", + howpublished="RFC 3599 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3599", + pages="1--34", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3599.txt", + key="RFC 3599", + abstract={This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs.}, + doi="10.17487/RFC3599", + } + +@misc{rfc3600, + author="J. {Reynolds (Ed.)} and S. {Ginoza (Ed.)}", + title="{Internet Official Protocol Standards}", + howpublished="RFC 3600 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3600", + pages="1--50", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3700", +url="https://www.rfc-editor.org/rfc/rfc3600.txt", + key="RFC 3600", + abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.}, + doi="10.17487/RFC3600", + } + +@misc{rfc3601, + author="C. Allocchio", + title="{Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses}", + howpublished="RFC 3601 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3601", + pages="1--10", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3601.txt", + key="RFC 3601", + abstract={This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional ``actions'' (such as ``wait for dialtone'', ``pause for N secs'', etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.}, + keywords="notations, dtmf, dual tone multifrequency, telephony, e-mail addresses, urls, integrated messaging, 3gpp", + doi="10.17487/RFC3601", + } + +@misc{rfc3602, + author="S. Frankel and R. Glenn and S. Kelly", + title="{The AES-CBC Cipher Algorithm and Its Use with IPsec}", + howpublished="RFC 3602 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3602", + pages="1--15", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3602.txt", + key="RFC 3602", + abstract={This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).}, + keywords="ipsec, encapsulating, security, payload", + doi="10.17487/RFC3602", + } + +@misc{rfc3603, + author="W. {Marshall (Ed.)} and F. {Andreasen (Ed.)}", + title="{Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture}", + howpublished="RFC 3603 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3603", + pages="1--28", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5503", +url="https://www.rfc-editor.org/rfc/rfc3603.txt", + key="RFC 3603", + abstract={In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coord ination of charging and other functions is required.}, + keywords="network access coordination", + doi="10.17487/RFC3603", + } + +@misc{rfc3604, + author="H. Khosravi and G. Kullgren and S. Shew and J. Sadler and A. Watanabe", + title="{Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)}", + howpublished="RFC 3604 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3604", + pages="1--16", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3604.txt", + key="RFC 3604", + abstract={This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.}, + keywords="controllers, routers, formats, codes", + doi="10.17487/RFC3604", + } + +@misc{rfc3605, + author="C. Huitema", + title="{Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)}", + howpublished="RFC 3605 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3605", + pages="1--8", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3605.txt", + key="RFC 3605", + abstract={The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.}, + keywords="nat, network access translation, port mapping", + doi="10.17487/RFC3605", + } + +@misc{rfc3606, + author="F. Ly and M. Noto and A. Smith and E. Spiegel and K. Tesink", + title="{Definitions of Supplemental Managed Objects for ATM Interface}", + howpublished="RFC 3606 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3606", + pages="1--94", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3606.txt", + key="RFC 3606", + abstract={This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs).}, + keywords="asynchronous transfer mode, mib, management information base", + doi="10.17487/RFC3606", + } + +@misc{rfc3607, + author="M. Leech", + title="{Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool}", + howpublished="RFC 3607 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3607", + pages="1--8", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3607.txt", + key="RFC 3607", + abstract={This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.}, + keywords="security encryption, des, data standard, distributed cryptanalysis, computer virus, network worm, codebreaking", + doi="10.17487/RFC3607", + } + +@misc{rfc3608, + author="D. Willis and B. Hoeneisen", + title="{Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration}", + howpublished="RFC 3608 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3608", + pages="1--17", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5630", +url="https://www.rfc-editor.org/rfc/rfc3608.txt", + key="RFC 3608", + abstract={This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.}, + keywords="user agent, domain, register", + doi="10.17487/RFC3608", + } + +@misc{rfc3609, + author="R. Bonica and K. Kompella and D. Meyer", + title="{Tracing Requirements for Generic Tunnels}", + howpublished="RFC 3609 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3609", + pages="1--9", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3609.txt", + key="RFC 3609", + abstract={This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that ``traceroute'' currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.}, + keywords="traceroute, application, IP, internet protocol", + doi="10.17487/RFC3609", + } + +@misc{rfc3610, + author="D. Whiting and R. Housley and N. Ferguson", + title="{Counter with CBC-MAC (CCM)}", + howpublished="RFC 3610 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3610", + pages="1--26", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3610.txt", + key="RFC 3610", + abstract={Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).}, + keywords="authentication, encryption, security, ciphers", + doi="10.17487/RFC3610", + } + +@misc{rfc3611, + author="T. {Friedman (Ed.)} and R. {Caceres (Ed.)} and A. {Clark (Ed.)}", + title="{RTP Control Protocol Extended Reports (RTCP XR)}", + howpublished="RFC 3611 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3611", + pages="1--55", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3611.txt", + key="RFC 3611", + abstract={This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.}, + keywords="real time transport protocol, packet, type, sdp, session description, blocks", + doi="10.17487/RFC3611", + } + +@misc{rfc3612, + author="A. Farrel", + title="{Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)}", + howpublished="RFC 3612 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3612", + pages="1--16", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3612.txt", + key="RFC 3612", + abstract={This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, ``Constraint-Based LSP Setup Using LDP''.}, + keywords="mpls, fault tolerence, high availability, multiprotocol label switching, cr-ldp, high availability restart", + doi="10.17487/RFC3612", + } + +@misc{rfc3613, + author="R. Morgan and K. Hazelton", + title="{Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)}", + howpublished="RFC 3613 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3613", + pages="1--8", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3613.txt", + key="RFC 3613", + abstract={This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE). This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.}, + keywords="internet2, middleware", + doi="10.17487/RFC3613", + } + +@misc{rfc3614, + author="J. Smith", + title="{A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG)}", + howpublished="RFC 3614 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3614", + pages="1--6", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3614.txt", + key="RFC 3614", + abstract={This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.}, + keywords="iso, international organization standardization, multimedia, metadata, xml, classification, schemes, digital rights management", + doi="10.17487/RFC3614", + } + +@misc{rfc3615, + author="J. Gustin and A. Goyens", + title="{A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging}", + howpublished="RFC 3615 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3615", + pages="1--5", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3615.txt", + key="RFC 3615", + abstract={This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.}, + keywords="messaging service, interface software", + doi="10.17487/RFC3615", + } + +@misc{rfc3616, + author="F. Bellifemine and I. Constantinescu and S. Willmott", + title="{A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA)}", + howpublished="RFC 3616 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3616", + pages="1--8", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3616.txt", + key="RFC 3616", + abstract={This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.}, + keywords="URN NID, Uniform Resource Name Namespace Identification", + doi="10.17487/RFC3616", + } + +@misc{rfc3617, + author="E. Lear", + title="{Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)}", + howpublished="RFC 3617 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3617", + pages="1--7", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3617.txt", + key="RFC 3617", + abstract={The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.}, + doi="10.17487/RFC3617", + } + +@misc{rfc3618, + author="B. {Fenner (Ed.)} and D. {Meyer (Ed.)}", + title="{Multicast Source Discovery Protocol (MSDP)}", + howpublished="RFC 3618 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3618", + pages="1--19", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3618.txt", + key="RFC 3618", + abstract={The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.}, + keywords="ipv4, pim-sm, independent multicast, sparse-mode, rp, rendezvous point", + doi="10.17487/RFC3618", + } + +@misc{rfc3619, + author="S. Shah and M. Yip", + title="{Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1}", + howpublished="RFC 3619 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3619", + pages="1--7", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3619.txt", + key="RFC 3619", + abstract={This document describes the Ethernet Automatic Protection Switching (EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).}, + keywords="ethernet rings, robust", + doi="10.17487/RFC3619", + } + +@misc{rfc3620, + author="D. New", + title="{The TUNNEL Profile}", + howpublished="RFC 3620 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3620", + pages="1--18", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3620.txt", + key="RFC 3620", + abstract={This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.}, + keywords="beep, blocks extensible exchange protocol, firewall, application layer", + doi="10.17487/RFC3620", + } + +@misc{rfc3621, + author="A. Berger and D. Romascanu", + title="{Power Ethernet MIB}", + howpublished="RFC 3621 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3621", + pages="1--20", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3621.txt", + key="RFC 3621", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).}, + keywords="management information base, data terminal equipment power, dte, power sourcing equipment, pse", + doi="10.17487/RFC3621", + } + +@misc{rfc3622, + author="M. Mealling", + title="{A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project}", + howpublished="RFC 3622 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3622", + pages="1--7", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3622.txt", + key="RFC 3622", + abstract={This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.}, + keywords="federated network identity", + doi="10.17487/RFC3622", + } + +@misc{rfc3623, + author="J. Moy and P. Pillay-Esnault and A. Lindem", + title="{Graceful OSPF Restart}", + howpublished="RFC 3623 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3623", + pages="1--18", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3623.txt", + key="RFC 3623", + abstract={This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called ``graceful restart'' or ``non-stop forwarding''. A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.}, + keywords="open shortest path first, non-stop forwarding", + doi="10.17487/RFC3623", + } + +@misc{rfc3624, + author="B. Foster and D. Auerbach and F. Andreasen", + title="{The Media Gateway Control Protocol (MGCP) Bulk Audit Package}", + howpublished="RFC 3624 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3624", + pages="1--19", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3624.txt", + key="RFC 3624", + abstract={The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.}, + keywords="call agent, endpoints, naming conventions", + doi="10.17487/RFC3624", + } + +@misc{rfc3625, + author="R. Gellens and H. Garudadri", + title="{The QCP File Format and Media Types for Speech Data}", + howpublished="RFC 3625 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3625", + pages="1--15", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3625.txt", + key="RFC 3625", + abstract={RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the ``QCP'' file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder (EVRC) and Selectable Mode Vocoders (SMV) data. (For example, Eudora(r), QuickTime(r), and cmda2000(r) handsets). This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC and SMV (respectively) data stored in this format.}, + keywords="13k, qcelp, audio, multimedia, voip, real time transport protocol, multipurpose internet mail extensions", + doi="10.17487/RFC3625", + } + +@misc{rfc3626, + author="T. {Clausen (Ed.)} and P. {Jacquet (Ed.)}", + title="{Optimized Link State Routing Protocol (OLSR)}", + howpublished="RFC 3626 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3626", + pages="1--75", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3626.txt", + key="RFC 3626", + abstract={This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.}, + keywords="mobile ad hoc, wireless multipoint relays, mpr, mprs", + doi="10.17487/RFC3626", + } + +@misc{rfc3627, + author="P. Savola", + title="{Use of /127 Prefix Length Between Routers Considered Harmful}", + howpublished="RFC 3627 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3627", + pages="1--6", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6547", +url="https://www.rfc-editor.org/rfc/rfc3627.txt", + key="RFC 3627", + abstract={In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.}, + keywords="address space, anycast", + doi="10.17487/RFC3627", + } + +@misc{rfc3628, + author="D. Pinkas and N. Pope and J. Ross", + title="{Policy Requirements for Time-Stamping Authorities (TSAs)}", + howpublished="RFC 3628 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3628", + pages="1--43", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3628.txt", + key="RFC 3628", + abstract={This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.}, + keywords="tokens, public key certificates", + doi="10.17487/RFC3628", + } + +@misc{rfc3629, + author="F. Yergeau", + title="{UTF-8, a transformation format of ISO 10646}", + howpublished="RFC 3629 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3629", + pages="1--14", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3629.txt", + key="RFC 3629", + abstract={ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.}, + keywords="UTF-8, UCS, Transformation, Format", + doi="10.17487/RFC3629", + } + +@misc{rfc3630, + author="D. Katz and K. Kompella and D. Yeung", + title="{Traffic Engineering (TE) Extensions to OSPF Version 2}", + howpublished="RFC 3630 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3630", + pages="1--14", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4203, 5786", +url="https://www.rfc-editor.org/rfc/rfc3630.txt", + key="RFC 3630", + abstract={This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.}, + keywords="open-shortest, path, first, ink, state, advertisement", + doi="10.17487/RFC3630", + } + +@misc{rfc3631, + author="S. {Bellovin (Ed.)} and J. {Schiller (Ed.)} and C. {Kaufman (Ed.)}", + title="{Security Mechanisms for the Internet}", + howpublished="RFC 3631 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3631", + pages="1--20", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3631.txt", + key="RFC 3631", + abstract={Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.}, + keywords="protocol, host compromise, dos, denial of service", + doi="10.17487/RFC3631", + } + +@misc{rfc3632, + author="S. Hollenbeck and S. Veeramachaneni and S. Yalamanchilli", + title="{VeriSign Registry Registrar Protocol (RRP) Version 2.0.0}", + howpublished="RFC 3632 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3632", + pages="1--8", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3632.txt", + key="RFC 3632", + abstract={This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.}, + keywords="RRP, shared, registration, system, gLTD, ccTLD, top level domain", + doi="10.17487/RFC3632", + } + +@misc{rfc3633, + author="O. Troan and R. Droms", + title="{IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6}", + howpublished="RFC 3633 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3633", + pages="1--19", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6603, 7550", +url="https://www.rfc-editor.org/rfc/rfc3633.txt", + key="RFC 3633", + abstract={The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.}, + keywords="automated delegation router", + doi="10.17487/RFC3633", + } + +@misc{rfc3634, + author="K. Luehrs and R. Woundy and J. Bevilacqua and N. Davoust", + title="{Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option}", + howpublished="RFC 3634 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3634", + pages="1--7", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3634.txt", + key="RFC 3634", + abstract={This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.}, + keywords="", + doi="10.17487/RFC3634", + } + +@misc{rfc3635, + author="J. Flick", + title="{Definitions of Managed Objects for the Ethernet-like Interface Types}", + howpublished="RFC 3635 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3635", + pages="1--64", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3635.txt", + key="RFC 3635", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.}, + keywords="MIB, management, information, base", + doi="10.17487/RFC3635", + } + +@misc{rfc3636, + author="J. Flick", + title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}", + howpublished="RFC 3636 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3636", + pages="1--62", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4836", +url="https://www.rfc-editor.org/rfc/rfc3636.txt", + key="RFC 3636", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.}, + keywords="MAU-MIB, management, information, base", + doi="10.17487/RFC3636", + } + +@misc{rfc3637, + author="C.M. {Heard (Ed.)}", + title="{Definitions of Managed Objects for the Ethernet WAN Interface Sublayer}", + howpublished="RFC 3637 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3637", + pages="1--37", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3637.txt", + key="RFC 3637", + abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.}, + keywords="mib, management information base", + doi="10.17487/RFC3637", + } + +@misc{rfc3638, + author="J. Flick and C. M. Heard", + title="{Applicability Statement for Reclassification of RFC 1643 to Historic Status}", + howpublished="RFC 3638 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3638", + pages="1--5", + year=2003, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3638.txt", + key="RFC 3638", + abstract={This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.}, + keywords="ETHER-MIB, MIB, Network, Management, SNMP, Ethernet", + doi="10.17487/RFC3638", + } + +@misc{rfc3639, + author="M. St. {Johns (Ed.)} and G. {Huston (Ed.)} and IAB", + title="{Considerations on the use of a Service Identifier in Packet Headers}", + howpublished="RFC 3639 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3639", + pages="1--8", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3639.txt", + key="RFC 3639", + abstract={This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.}, + keywords="port fields, protocol number", + doi="10.17487/RFC3639", + } + +@misc{rfc3640, + author="J. van der Meer and D. Mackie and V. Swaminathan and D. Singer and P. Gentric", + title="{RTP Payload Format for Transport of MPEG-4 Elementary Streams}", + howpublished="RFC 3640 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3640", + pages="1--43", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5691", +url="https://www.rfc-editor.org/rfc/rfc3640.txt", + key="RFC 3640", + abstract={The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.}, + keywords="real time transport protocol, audio video streams", + doi="10.17487/RFC3640", + } + +@misc{rfc3641, + author="S. Legg", + title="{Generic String Encoding Rules (GSER) for ASN.1 Types}", + howpublished="RFC 3641 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3641", + pages="1--16", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4792", +url="https://www.rfc-editor.org/rfc/rfc3641.txt", + key="RFC 3641", + abstract={This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.}, + keywords="asn.1, abstract syntax notation", + doi="10.17487/RFC3641", + } + +@misc{rfc3642, + author="S. Legg", + title="{Common Elements of Generic String Encoding Rules (GSER) Encodings}", + howpublished="RFC 3642 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3642", + pages="1--13", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3642.txt", + key="RFC 3642", + abstract={The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.}, + keywords="asn.1, abstract syntax notation", + doi="10.17487/RFC3642", + } + +@misc{rfc3643, + author="R. Weber and M. Rajagopal and F. Travostino and M. O'Donnell and C. Monia and M. Merhar", + title="{Fibre Channel (FC) Frame Encapsulation}", + howpublished="RFC 3643 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3643", + pages="1--20", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3643.txt", + key="RFC 3643", + abstract={This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.}, + keywords="ips, ip storage, frame header", + doi="10.17487/RFC3643", + } + +@misc{rfc3644, + author="Y. Snir and Y. Ramberg and J. Strassner and R. Cohen and B. Moore", + title="{Policy Quality of Service (QoS) Information Model}", + howpublished="RFC 3644 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3644", + pages="1--73", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3644.txt", + key="RFC 3644", + abstract={This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.}, + keywords="integrated differentiated, object oriented", + doi="10.17487/RFC3644", + } + +@misc{rfc3645, + author="S. Kwan and P. Garg and J. Gilroy and L. Esibov and J. Westhead and R. Hall", + title="{Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)}", + howpublished="RFC 3645 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3645", + pages="1--26", + year=2003, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3645.txt", + key="RFC 3645", + abstract={The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.}, + keywords="TSIG, domain name system, transaction, signature", + doi="10.17487/RFC3645", + } + +@misc{rfc3646, + author="R. {Droms (Ed.)}", + title="{DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}", + howpublished="RFC 3646 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3646", + pages="1--7", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3646.txt", + key="RFC 3646", + abstract={This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.}, + keywords="domain name system, service, server, client", + doi="10.17487/RFC3646", + } + +@misc{rfc3647, + author="S. Chokhani and W. Ford and R. Sabett and C. Merrill and S. Wu", + title="{Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework}", + howpublished="RFC 3647 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3647", + pages="1--94", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3647.txt", + key="RFC 3647", + abstract={This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.}, + keywords="pkix, encryption, security, authentication", + doi="10.17487/RFC3647", + } + +@misc{rfc3648, + author="J. Whitehead and J. {Reschke (Ed.)}", + title="{Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol}", + howpublished="RFC 3648 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3648", + pages="1--30", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3648.txt", + key="RFC 3648", + abstract={This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.}, + keywords="server client semantics, ordering, orderpatch method, position header, ordering-type header", + doi="10.17487/RFC3648", + } + +@misc{rfc3649, + author="S. Floyd", + title="{HighSpeed TCP for Large Congestion Windows}", + howpublished="RFC 3649 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3649", + pages="1--34", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3649.txt", + key="RFC 3649", + abstract={The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,0 00,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.}, + keywords="transmission control protocol, round-trip, rate packet", + doi="10.17487/RFC3649", + } + +@misc{rfc3650, + author="S. Sun and L. Lannom and B. Boesch", + title="{Handle System Overview}", + howpublished="RFC 3650 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3650", + pages="1--21", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3650.txt", + key="RFC 3650", + abstract={This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.}, + keywords="name service", + doi="10.17487/RFC3650", + } + +@misc{rfc3651, + author="S. Sun and S. Reilly and L. Lannom", + title="{Handle System Namespace and Service Definition}", + howpublished="RFC 3651 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3651", + pages="1--41", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3651.txt", + key="RFC 3651", + abstract={The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.}, + keywords="name service", + doi="10.17487/RFC3651", + } + +@misc{rfc3652, + author="S. Sun and S. Reilly and L. Lannom and J. Petrone", + title="{Handle System Protocol (ver 2.1) Specification}", + howpublished="RFC 3652 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3652", + pages="1--53", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3652.txt", + key="RFC 3652", + abstract={The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.}, + keywords="name service", + doi="10.17487/RFC3652", + } + +@misc{rfc3653, + author="J. Boyer and M. Hughes and J. Reagle", + title="{XML-Signature XPath Filter 2.0}", + howpublished="RFC 3653 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3653", + pages="1--15", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3653.txt", + key="RFC 3653", + abstract={XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. This document is the W3C XML Signature XPath-Filter 2.0 Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document . W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.}, + keywords="extensible markup language, digital signature", + doi="10.17487/RFC3653", + } + +@misc{rfc3654, + author="H. {Khosravi (Ed.)} and T. {Anderson (Ed.)}", + title="{Requirements for Separation of IP Control and Forwarding}", + howpublished="RFC 3654 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3654", + pages="1--18", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3654.txt", + key="RFC 3654", + abstract={This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.}, + keywords="forces, forwarding control, element separation data", + doi="10.17487/RFC3654", + } + +@misc{rfc3655, + author="B. Wellington and O. Gudmundsson", + title="{Redefinition of DNS Authenticated Data (AD) bit}", + howpublished="RFC 3655 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3655", + pages="1--8", + year=2003, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035", +url="https://www.rfc-editor.org/rfc/rfc3655.txt", + key="RFC 3655", + abstract={This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.}, + keywords="DNS-SECEXT, dns, authentication", + doi="10.17487/RFC3655", + } + +@misc{rfc3656, + author="R. Siemborski", + title="{The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol}", + howpublished="RFC 3656 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3656", + pages="1--19", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3656.txt", + key="RFC 3656", + abstract={As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.}, + keywords="imap, pop3, post office protocol, internet message access", + doi="10.17487/RFC3656", + } + +@misc{rfc3657, + author="S. Moriai and A. Kato", + title="{Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 3657 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3657", + pages="1--14", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3657.txt", + key="RFC 3657", + abstract={This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).}, + keywords="security, mail content, key", + doi="10.17487/RFC3657", + } + +@misc{rfc3658, + author="O. Gudmundsson", + title="{Delegation Signer (DS) Resource Record (RR)}", + howpublished="RFC 3658 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3658", + pages="1--19", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFC 3755", +url="https://www.rfc-editor.org/rfc/rfc3658.txt", + key="RFC 3658", + abstract={The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.}, + keywords="zone cut, zone key, security, dns, domain name system", + doi="10.17487/RFC3658", + } + +@misc{rfc3659, + author="P. Hethmon", + title="{Extensions to FTP}", + howpublished="RFC 3659 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3659", + pages="1--61", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3659.txt", + key="RFC 3659", + abstract={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]}, + keywords="FTP, file transfer protocol, stream mode, data transfer storage", + doi="10.17487/RFC3659", + } + +@misc{rfc3660, + author="B. Foster and F. Andreasen", + title="{Basic Media Gateway Control Protocol (MGCP) Packages}", + howpublished="RFC 3660 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3660", + pages="1--64", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3660.txt", + key="RFC 3660", + abstract={This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.}, + keywords="generic, line, trunk, handset, dtmf, dual tone multifrequency", + doi="10.17487/RFC3660", + } + +@misc{rfc3661, + author="B. Foster and C. Sivachelvan", + title="{Media Gateway Control Protocol (MGCP) Return Code Usage}", + howpublished="RFC 3661 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3661", + pages="1--24", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3661.txt", + key="RFC 3661", + abstract={This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP) Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.}, + keywords="guidelines, call agent, implementation", + doi="10.17487/RFC3661", + } + +@misc{rfc3662, + author="R. Bless and K. Nichols and K. Wehrle", + title="{A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services}", + howpublished="RFC 3662 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3662", + pages="1--17", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3662.txt", + key="RFC 3662", + abstract={This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be ``starved'' (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's ``best-effort'' or ``normal Internet traffic'' model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a ``lower'' priority than the normal ``best-effort'' Internet traffic, thus the PDB is called ``Lower Effort'' (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on ``best-effort''/``normal'' or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.}, + keywords="traffic network, ds, le", + doi="10.17487/RFC3662", + } + +@misc{rfc3663, + author="A. Newton", + title="{Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)}", + howpublished="RFC 3663 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3663", + pages="1--21", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3663.txt", + key="RFC 3663", + abstract={Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.}, + keywords="referral types, well-known", + doi="10.17487/RFC3663", + } + +@misc{rfc3664, + author="P. Hoffman", + title="{The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)}", + howpublished="RFC 3664 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3664", + pages="1--4", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4434", +url="https://www.rfc-editor.org/rfc/rfc3664.txt", + key="RFC 3664", + abstract={Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128.}, + keywords="security, ipsec, advanced encryption standard, mac, message authentication code", + doi="10.17487/RFC3664", + } + +@misc{rfc3665, + author="A. Johnston and S. Donovan and R. Sparks and C. Cunningham and K. Summers", + title="{Session Initiation Protocol (SIP) Basic Call Flow Examples}", + howpublished="RFC 3665 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3665", + pages="1--94", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3665.txt", + key="RFC 3665", + abstract={This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.}, + keywords="user agent, client proxy, redirect", + doi="10.17487/RFC3665", + } + +@misc{rfc3666, + author="A. Johnston and S. Donovan and R. Sparks and C. Cunningham and K. Summers", + title="{Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows}", + howpublished="RFC 3666 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3666", + pages="1--118", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3666.txt", + key="RFC 3666", + abstract={This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.}, + keywords="user proxy, gateway, telephony", + doi="10.17487/RFC3666", + } + +@misc{rfc3667, + author="S. Bradner", + title="{IETF Rights in Contributions}", + howpublished="RFC 3667 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3667", + pages="1--18", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3978", +url="https://www.rfc-editor.org/rfc/rfc3667.txt", + key="RFC 3667", + abstract={The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="intellectual property rights, copyright, ipr", + doi="10.17487/RFC3667", + } + +@misc{rfc3668, + author="S. Bradner", + title="{Intellectual Property Rights in IETF Technology}", + howpublished="RFC 3668 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3668", + pages="1--17", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 3979", +url="https://www.rfc-editor.org/rfc/rfc3668.txt", + key="RFC 3668", + abstract={The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="ipr, copyright", + doi="10.17487/RFC3668", + } + +@misc{rfc3669, + author="S. Brim", + title="{Guidelines for Working Groups on Intellectual Property Issues}", + howpublished="RFC 3669 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3669", + pages="1--17", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3669.txt", + key="RFC 3669", + abstract={This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. This memo provides information for the Internet community.}, + keywords="ipr, copyright", + doi="10.17487/RFC3669", + } + +@misc{rfc3670, + author="B. Moore and D. Durham and J. Strassner and A. Westerinen and W. Weiss", + title="{Information Model for Describing Network Device QoS Datapath Mechanisms}", + howpublished="RFC 3670 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3670", + pages="1--97", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3670.txt", + key="RFC 3670", + abstract={The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent informatio n independent of a binding to a specific type of repository}, + keywords="quality of service, host, netowrk devices, traffic", + doi="10.17487/RFC3670", + } + +@misc{rfc3671, + author="K. Zeilenga", + title="{Collective Attributes in the Lightweight Directory Access Protocol (LDAP)}", + howpublished="RFC 3671 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3671", + pages="1--10", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3671.txt", + key="RFC 3671", + abstract={X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP.}, + keywords="x.500, information model schema", + doi="10.17487/RFC3671", + } + +@misc{rfc3672, + author="K. Zeilenga", + title="{Subentries in the Lightweight Directory Access Protocol (LDAP)}", + howpublished="RFC 3672 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3672", + pages="1--12", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3672.txt", + key="RFC 3672", + abstract={In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).}, + keywords="special subtree", + doi="10.17487/RFC3672", + } + +@misc{rfc3673, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes}", + howpublished="RFC 3673 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3673", + pages="1--5", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3673.txt", + key="RFC 3673", + abstract={The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.}, + keywords="user mechanisms, extension", + doi="10.17487/RFC3673", + } + +@misc{rfc3674, + author="K. Zeilenga", + title="{Feature Discovery in Lightweight Directory Access Protocol (LDAP)}", + howpublished="RFC 3674 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3674", + pages="1--5", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4512", +url="https://www.rfc-editor.org/rfc/rfc3674.txt", + key="RFC 3674", + abstract={The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.}, + keywords="elective extensions, mechanisms", + doi="10.17487/RFC3674", + } + +@misc{rfc3675, + author="D. {Eastlake 3rd}", + title="{.sex Considered Dangerous}", + howpublished="RFC 3675 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3675", + pages="1--22", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3675.txt", + key="RFC 3675", + abstract={Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag ``adult'' or ``unsafe'' material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.}, + keywords="top level domains, tld, ip addresses, internet protocol filters", + doi="10.17487/RFC3675", + } + +@misc{rfc3676, + author="R. Gellens", + title="{The Text/Plain Format and DelSp Parameters}", + howpublished="RFC 3676 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3676", + pages="1--20", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3676.txt", + key="RFC 3676", + abstract={This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting. This document supersedes the one specified in RFC 2646, ``The Text/Plain Format Parameter'', and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. [STANDARDS-TRACK]}, + keywords="media type, mime, multipurpose, internet, mail, extension", + doi="10.17487/RFC3676", + } + +@misc{rfc3677, + author="L. {Daigle (Ed.)} and Internet Architecture Board", + title="{IETF ISOC Board of Trustee Appointment Procedures}", + howpublished="RFC 3677 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3677", + pages="1--7", + year=2003, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3677.txt", + key="RFC 3677", + abstract={This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.}, + keywords="internet society, bot, engineering task force", + doi="10.17487/RFC3677", + } + +@misc{rfc3678, + author="D. Thaler and B. Fenner and B. Quinn", + title="{Socket Interface Extensions for Multicast Source Filters}", + howpublished="RFC 3678 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3678", + pages="1--18", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3678.txt", + key="RFC 3678", + abstract={The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.}, + keywords="ip, internet protocol, application program interface, apis, input, output", + doi="10.17487/RFC3678", + } + +@misc{rfc3679, + author="R. Droms", + title="{Unused Dynamic Host Configuration Protocol (DHCP) Option Codes}", + howpublished="RFC 3679 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3679", + pages="1--8", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3679.txt", + key="RFC 3679", + abstract={Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.}, + keywords="dynamic, host, configuration, protocol, internet, assigned, numbers, authority", + doi="10.17487/RFC3679", + } + +@misc{rfc3680, + author="J. Rosenberg", + title="{A Session Initiation Protocol (SIP) Event Package for Registrations}", + howpublished="RFC 3680 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3680", + pages="1--26", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6140", +url="https://www.rfc-editor.org/rfc/rfc3680.txt", + key="RFC 3680", + abstract={This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS-TRACK]}, + keywords="REGISTER, event package name, event package parameters", + doi="10.17487/RFC3680", + } + +@misc{rfc3681, + author="R. Bush and R. Fink", + title="{Delegation of E.F.F.3.IP6.ARPA}", + howpublished="RFC 3681 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3681", + pages="1--4", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3681.txt", + key="RFC 3681", + abstract={This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.}, + keywords="dns, domain name system", + doi="10.17487/RFC3681", + } + +@misc{rfc3682, + author="V. Gill and J. Heasley and D. Meyer", + title="{The Generalized TTL Security Mechanism (GTSM)}", + howpublished="RFC 3682 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3682", + pages="1--11", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5082", +url="https://www.rfc-editor.org/rfc/rfc3682.txt", + key="RFC 3682", + abstract={The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. This memo defines an Experimental Protocol for the Internet community.}, + keywords="time to live, packet hop limit", + doi="10.17487/RFC3682", + } + +@misc{rfc3683, + author="M. Rose", + title="{A Practice for Revoking Posting Rights to IETF Mailing Lists}", + howpublished="RFC 3683 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3683", + pages="1--13", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3683.txt", + key="RFC 3683", + abstract={All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a ``denial-of-service'' attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC3683", + } + +@misc{rfc3684, + author="R. Ogier and F. Templin and M. Lewis", + title="{Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)}", + howpublished="RFC 3684 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3684", + pages="1--46", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3684.txt", + key="RFC 3684", + abstract={Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using ``differential'' HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. This memo defines an Experimental Protocol for the Internet community.}, + keywords="proactive routing, ad-hoc networks, neighbor discovery, link-state routing, mobile ad-hoc network, mobile mesh network, packet radio network, wireless communications", + doi="10.17487/RFC3684", + } + +@misc{rfc3685, + author="C. Daboo", + title="{SIEVE Email Filtering: Spamtest and VirusTest Extensions}", + howpublished="RFC 3685 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3685", + pages="1--9", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5235", +url="https://www.rfc-editor.org/rfc/rfc3685.txt", + key="RFC 3685", + abstract={The SIEVE mail filtering language ``spamtest'' and ``virustest'' extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]}, + keywords="messages, portable commands", + doi="10.17487/RFC3685", + } + +@misc{rfc3686, + author="R. Housley", + title="{Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)}", + howpublished="RFC 3686 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3686", + pages="1--19", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3686.txt", + key="RFC 3686", + abstract={This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.}, + keywords="authentication vector, cipher block", + doi="10.17487/RFC3686", + } + +@misc{rfc3687, + author="S. Legg", + title="{Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules}", + howpublished="RFC 3687 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3687", + pages="1--42", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3687.txt", + key="RFC 3687", + abstract={The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. [PROPOSED STANDARD]}, + keywords="syntax data schema", + doi="10.17487/RFC3687", + } + +@misc{rfc3688, + author="M. Mealling", + title="{The IETF XML Registry}", + howpublished="RFC 3688 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3688", + pages="1--8", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3688.txt", + key="RFC 3688", + abstract={This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.}, + keywords="extensible markup language", + doi="10.17487/RFC3688", + } + +@misc{rfc3689, + author="K. Carlberg and R. Atkinson", + title="{General Requirements for Emergency Telecommunication Service (ETS)}", + howpublished="RFC 3689 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3689", + pages="1--10", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3689.txt", + key="RFC 3689", + abstract={This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). This memo provides information for the Internet community.}, + doi="10.17487/RFC3689", + } + +@misc{rfc3690, + author="K. Carlberg and R. Atkinson", + title="{IP Telephony Requirements for Emergency Telecommunication Service (ETS)}", + howpublished="RFC 3690 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3690", + pages="1--7", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3690.txt", + key="RFC 3690", + abstract={This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.}, + doi="10.17487/RFC3690", + } + +@misc{rfc3691, + author="A. Melnikov", + title="{Internet Message Access Protocol (IMAP) UNSELECT command}", + howpublished="RFC 3691 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3691", + pages="1--5", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3691.txt", + key="RFC 3691", + abstract={This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. [STANDARDS-TRACK]}, + keywords="mailbox session client", + doi="10.17487/RFC3691", + } + +@misc{rfc3692, + author="T. Narten", + title="{Assigning Experimental and Testing Numbers Considered Useful}", + howpublished="RFC 3692 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3692", + pages="1--7", + year=2004, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3692.txt", + key="RFC 3692", + abstract={When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.}, + keywords="iana, internet assigned numbers authority, values, implementations", + doi="10.17487/RFC3692", + } + +@misc{rfc3693, + author="J. Cuellar and J. Morris and D. Mulligan and J. Peterson and J. Polk", + title="{Geopriv Requirements}", + howpublished="RFC 3693 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3693", + pages="1--30", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6280, 7459", +url="https://www.rfc-editor.org/rfc/rfc3693.txt", + key="RFC 3693", + abstract={Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. This memo provides information for the Internet community.}, + keywords="security privacy, lo, location object", + doi="10.17487/RFC3693", + } + +@misc{rfc3694, + author="M. Danley and D. Mulligan and J. Morris and J. Peterson", + title="{Threat Analysis of the Geopriv Protocol}", + howpublished="RFC 3694 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3694", + pages="1--18", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6280", +url="https://www.rfc-editor.org/rfc/rfc3694.txt", + key="RFC 3694", + abstract={This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. This memo provides information for the Internet community.}, + keywords="privacy security, data information", + doi="10.17487/RFC3694", + } + +@misc{rfc3695, + author="M. Luby and L. Vicisano", + title="{Compact Forward Error Correction (FEC) Schemes}", + howpublished="RFC 3695 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3695", + pages="1--13", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5445", +url="https://www.rfc-editor.org/rfc/rfc3695.txt", + key="RFC 3695", + abstract={This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. This memo defines an Experimental Protocol for the Internet community.}, + keywords="content, stream, delivery, multicast, internet protocol", + doi="10.17487/RFC3695", + } + +@misc{rfc3696, + author="J. Klensin", + title="{Application Techniques for Checking and Transformation of Names}", + howpublished="RFC 3696 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3696", + pages="1--16", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3696.txt", + key="RFC 3696", + abstract={Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. This memo provides information for the Internet community.}, + keywords="top-level domains, tlds", + doi="10.17487/RFC3696", + } + +@misc{rfc3697, + author="J. Rajahalme and A. Conta and B. Carpenter and S. Deering", + title="{IPv6 Flow Label Specification}", + howpublished="RFC 3697 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3697", + pages="1--9", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6437", +url="https://www.rfc-editor.org/rfc/rfc3697.txt", + key="RFC 3697", + abstract={This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]}, + keywords="nodes, packets", + doi="10.17487/RFC3697", + } + +@misc{rfc3698, + author="K. {Zeilenga (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): Additional Matching Rules}", + howpublished="RFC 3698 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3698", + pages="1--9", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4517", +url="https://www.rfc-editor.org/rfc/rfc3698.txt", + key="RFC 3698", + abstract={This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol, directory services", + doi="10.17487/RFC3698", + } + +@misc{rfc3700, + author="J. {Reynolds (Ed.)} and S. {Ginoza (Ed.)}", + title="{Internet Official Protocol Standards}", + howpublished="RFC 3700 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3700", + pages="1--54", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5000", +url="https://www.rfc-editor.org/rfc/rfc3700.txt", + key="RFC 3700", + abstract={This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3700", + } + +@misc{rfc3701, + author="R. Fink and R. Hinden", + title="{6bone (IPv6 Testing Address Allocation) Phaseout}", + howpublished="RFC 3701 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3701", + pages="1--6", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3701.txt", + key="RFC 3701", + abstract={The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, ``IPv6 Testing Address Allocation'', December, 1998. RFC 2471 will become historic. This memo provides information for the Internet community.}, + keywords="internet, protocol, protocotype, software, architecture", + doi="10.17487/RFC3701", + } + +@misc{rfc3702, + author="J. Loughney and G. Camarillo", + title="{Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3702 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3702", + pages="1--15", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3702.txt", + key="RFC 3702", + abstract={As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. This memo provides information for the Internet community.}, + doi="10.17487/RFC3702", + } + +@misc{rfc3703, + author="J. Strassner and B. Moore and R. Moats and E. Ellesson", + title="{Policy Core Lightweight Directory Access Protocol (LDAP) Schema}", + howpublished="RFC 3703 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3703", + pages="1--61", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4104", +url="https://www.rfc-editor.org/rfc/rfc3703.txt", + key="RFC 3703", + abstract={This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. [STANDARDS-TRACK]}, + keywords="mapping classes", + doi="10.17487/RFC3703", + } + +@misc{rfc3704, + author="F. Baker and P. Savola", + title="{Ingress Filtering for Multihomed Networks}", + howpublished="RFC 3704 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3704", + pages="1--16", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3704.txt", + key="RFC 3704", + abstract={BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="ISP, Internet Service Provider, Internet Protocol, DOS", + doi="10.17487/RFC3704", + } + +@misc{rfc3705, + author="B. Ray and R. Abbi", + title="{High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals}", + howpublished="RFC 3705 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3705", + pages="1--11", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3705.txt", + key="RFC 3705", + abstract={This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS-TRACK]}, + keywords="management information base", + doi="10.17487/RFC3705", + } + +@misc{rfc3706, + author="G. Huang and S. Beaulieu and D. Rochefort", + title="{A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers}", + howpublished="RFC 3706 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3706", + pages="1--13", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3706.txt", + key="RFC 3706", + abstract={This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. This memo provides information for the Internet community.}, + keywords="security authentication, dead peer detection, dpd, keepalive", + doi="10.17487/RFC3706", + } + +@misc{rfc3707, + author="A. Newton", + title="{Cross Registry Internet Service Protocol (CRISP) Requirements}", + howpublished="RFC 3707 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3707", + pages="1--26", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3707.txt", + key="RFC 3707", + abstract={Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. This memo provides information for the Internet community.}, + keywords="directory services domain", + doi="10.17487/RFC3707", + } + +@misc{rfc3708, + author="E. Blanton and M. Allman", + title="{Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions}", + howpublished="RFC 3708 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3708", + pages="1--9", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3708.txt", + key="RFC 3708", + abstract={TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC3708", + } + +@misc{rfc3709, + author="S. Santesson and R. Housley and T. Freeman", + title="{Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates}", + howpublished="RFC 3709 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3709", + pages="1--21", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6170", +url="https://www.rfc-editor.org/rfc/rfc3709.txt", + key="RFC 3709", + abstract={This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]}, + keywords="authentication, security identification", + doi="10.17487/RFC3709", + } + +@misc{rfc3710, + author="H. Alvestrand", + title="{An IESG charter}", + howpublished="RFC 3710 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3710", + pages="1--12", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 3932, 5742", +url="https://www.rfc-editor.org/rfc/rfc3710.txt", + key="RFC 3710", + abstract={This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community.}, + keywords="internet engineering steering group", + doi="10.17487/RFC3710", + } + +@misc{rfc3711, + author="M. Baugher and D. McGrew and M. Naslund and E. Carrara and K. Norrman", + title="{The Secure Real-time Transport Protocol (SRTP)}", + howpublished="RFC 3711 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3711", + pages="1--56", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5506, 6904", +url="https://www.rfc-editor.org/rfc/rfc3711.txt", + key="RFC 3711", + abstract={This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]}, + keywords="authentication, traffic, cryptographic", + doi="10.17487/RFC3711", + } + +@misc{rfc3712, + author="P. Fleming and I. McDonald", + title="{Lightweight Directory Access Protocol (LDAP): Schema for Printer Services}", + howpublished="RFC 3712 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3712", + pages="1--33", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7612", +url="https://www.rfc-editor.org/rfc/rfc3712.txt", + key="RFC 3712", + abstract={This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). This memo provides information for the Internet community.}, + keywords="object classes, attributes", + doi="10.17487/RFC3712", + } + +@misc{rfc3713, + author="M. Matsui and J. Nakajima and S. Moriai", + title="{A Description of the Camellia Encryption Algorithm}", + howpublished="RFC 3713 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3713", + pages="1--15", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3713.txt", + key="RFC 3713", + abstract={This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. This memo provides information for the Internet community.}, + keywords="security, key, cryptographic", + doi="10.17487/RFC3713", + } + +@misc{rfc3714, + author="S. {Floyd (Ed.)} and J. {Kempf (Ed.)}", + title="{IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet}", + howpublished="RFC 3714 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3714", + pages="1--32", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3714.txt", + key="RFC 3714", + abstract={This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. This memo provides information for the Internet community.}, + keywords="end-to-end, qos, qualify of service, voip, internet protocol", + doi="10.17487/RFC3714", + } + +@misc{rfc3715, + author="B. Aboba and W. Dixon", + title="{IPsec-Network Address Translation (NAT) Compatibility Requirements}", + howpublished="RFC 3715 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3715", + pages="1--18", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3715.txt", + key="RFC 3715", + abstract={This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This memo provides information for the Internet community.}, + keywords="virtual private networks, vpns, intranet", + doi="10.17487/RFC3715", + } + +@misc{rfc3716, + author="IAB Advisory Committee", + title="{The IETF in the Large: Administration and Execution}", + howpublished="RFC 3716 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3716", + pages="1--40", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3716.txt", + key="RFC 3716", + abstract={In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself. This memo provides information for the Internet community.}, + doi="10.17487/RFC3716", + } + +@misc{rfc3717, + author="B. Rajagopalan and J. Luciani and D. Awduche", + title="{IP over Optical Networks: A Framework}", + howpublished="RFC 3717 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3717", + pages="1--48", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3717.txt", + key="RFC 3717", + abstract={The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as ``IP over optical networks''). This memo provides information for the Internet community.}, + keywords="transport infrastructure, routers, high-speed", + doi="10.17487/RFC3717", + } + +@misc{rfc3718, + author="R. McGowan", + title="{A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access}", + howpublished="RFC 3718 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3718", + pages="1--11", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3718.txt", + key="RFC 3718", + abstract={This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding \& standardization processes.}, + doi="10.17487/RFC3718", + } + +@misc{rfc3719, + author="J. {Parker (Ed.)}", + title="{Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)}", + howpublished="RFC 3719 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3719", + pages="1--15", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3719.txt", + key="RFC 3719", + abstract={This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. This memo provides information for the Internet community.}, + keywords="routing, routeing, interior gateway protocol, igp, conformance, ip traffic", + doi="10.17487/RFC3719", + } + +@misc{rfc3720, + author="J. Satran and K. Meth and C. Sapuntzakis and M. Chadalapaka and E. Zeidner", + title="{Internet Small Computer Systems Interface (iSCSI)}", + howpublished="RFC 3720 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3720", + pages="1--257", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7143, updated by RFCs 3980, 4850, 5048, 7146", +url="https://www.rfc-editor.org/rfc/rfc3720.txt", + key="RFC 3720", + abstract={This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to ``carry'' SCSI. [STANDARDS-TRACK]}, + keywords="transport protocol, tcp, transmission control protocol", + doi="10.17487/RFC3720", + } + +@misc{rfc3721, + author="M. Bakke and J. Hafner and J. Hufferd and K. Voruganti and M. Krueger", + title="{Internet Small Computer Systems Interface (iSCSI) Naming and Discovery}", + howpublished="RFC 3721 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3721", + pages="1--22", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7143", +url="https://www.rfc-editor.org/rfc/rfc3721.txt", + key="RFC 3721", + abstract={This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. This memo provides information for the Internet community.}, + keywords="targets, environments, scalibilty, target, initiator, scsi, device name", + doi="10.17487/RFC3721", + } + +@misc{rfc3722, + author="M. Bakke", + title="{String Profile for Internet Small Computer Systems Interface (iSCSI) Names}", + howpublished="RFC 3722 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3722", + pages="1--8", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3722.txt", + key="RFC 3722", + abstract={This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. [STANDARDS-TRACK]}, + keywords="transport, unique, global", + doi="10.17487/RFC3722", + } + +@misc{rfc3723, + author="B. Aboba and J. Tseng and J. Walker and V. Rangan and F. Travostino", + title="{Securing Block Storage Protocols over IP}", + howpublished="RFC 3723 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3723", + pages="1--70", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc3723.txt", + key="RFC 3723", + abstract={This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. [STANDARDS-TRACK]}, + keywords="internet, threat models, performance, security", + doi="10.17487/RFC3723", + } + +@misc{rfc3724, + author="J. {Kempf (Ed.)} and R. {Austein (Ed.)} and IAB", + title="{The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture}", + howpublished="RFC 3724 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3724", + pages="1--14", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3724.txt", + key="RFC 3724", + abstract={The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.}, + keywords="architectural guideline", + doi="10.17487/RFC3724", + } + +@misc{rfc3725, + author="J. Rosenberg and J. Peterson and H. Schulzrinne and G. Camarillo", + title="{Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)}", + howpublished="RFC 3725 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3725", + pages="1--31", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3725.txt", + key="RFC 3725", + abstract={Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC3725", + } + +@misc{rfc3726, + author="M. {Brunner (Ed.)}", + title="{Requirements for Signaling Protocols}", + howpublished="RFC 3726 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3726", + pages="1--42", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3726.txt", + key="RFC 3726", + abstract={This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This memo provides information for the Internet community.}, + keywords="rsvp, resource reservation protocol, middleboxes, nsis", + doi="10.17487/RFC3726", + } + +@misc{rfc3727, + author="S. Legg", + title="{ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules}", + howpublished="RFC 3727 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3727", + pages="1--5", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3727.txt", + key="RFC 3727", + abstract={This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS-TRACK]}, + keywords="lightweight directory access protocol", + doi="10.17487/RFC3727", + } + +@misc{rfc3728, + author="B. Ray and R. Abbi", + title="{Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)}", + howpublished="RFC 3728 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3728", + pages="1--76", + year=2004, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3728.txt", + key="RFC 3728", + abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. [STANDARDS-TRACK]}, + keywords="management information base, mib", + doi="10.17487/RFC3728", + } + +@misc{rfc3729, + author="S. Waldbusser", + title="{Application Performance Measurement MIB}", + howpublished="RFC 3729 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3729", + pages="1--61", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3729.txt", + key="RFC 3729", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for measuring the application performance as experienced by end-users. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3729", + } + +@misc{rfc3730, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 3730 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3730", + pages="1--69", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4930", +url="https://www.rfc-editor.org/rfc/rfc3730.txt", + key="RFC 3730", + abstract={This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. [STANDARDS-TRACK]}, + keywords="shared framework mapping", + doi="10.17487/RFC3730", + } + +@misc{rfc3731, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Domain Name Mapping}", + howpublished="RFC 3731 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3731", + pages="1--45", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4931", +url="https://www.rfc-editor.org/rfc/rfc3731.txt", + key="RFC 3731", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. [STANDARDS-TRACK]}, + keywords="syntax, semantics", + doi="10.17487/RFC3731", + } + +@misc{rfc3732, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Host Mapping}", + howpublished="RFC 3732 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3732", + pages="1--28", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4932", +url="https://www.rfc-editor.org/rfc/rfc3732.txt", + key="RFC 3732", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. [STANDARDS-TRACK]}, + keywords="syntax, semantics", + doi="10.17487/RFC3732", + } + +@misc{rfc3733, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Contact Mapping}", + howpublished="RFC 3733 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3733", + pages="1--41", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4933", +url="https://www.rfc-editor.org/rfc/rfc3733.txt", + key="RFC 3733", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ``contacts'') stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. [STANDARDS-TRACK]}, + keywords="syntax, semantics", + doi="10.17487/RFC3733", + } + +@misc{rfc3734, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Transport Over TCP}", + howpublished="RFC 3734 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3734", + pages="1--9", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4934", +url="https://www.rfc-editor.org/rfc/rfc3734.txt", + key="RFC 3734", + abstract={This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS-TRACK]}, + keywords="mapping, client, server, tls, transport layer security", + doi="10.17487/RFC3734", + } + +@misc{rfc3735, + author="S. Hollenbeck", + title="{Guidelines for Extending the Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 3735 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3735", + pages="1--13", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3735.txt", + key="RFC 3735", + abstract={The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. This memo provides information for the Internet community.}, + doi="10.17487/RFC3735", + } + +@misc{rfc3736, + author="R. Droms", + title="{Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6}", + howpublished="RFC 3736 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3736", + pages="1--9", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3736.txt", + key="RFC 3736", + abstract={Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3736", + } + +@misc{rfc3737, + author="B. Wijnen and A. Bierman", + title="{IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules}", + howpublished="RFC 3737 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3737", + pages="1--7", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3737.txt", + key="RFC 3737", + abstract={This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root. This memo also documents the currently assigned values. [STANDARDS-TRACK]}, + keywords="management information base, internet assigned numbers authority", + doi="10.17487/RFC3737", + } + +@misc{rfc3738, + author="M. Luby and V. Goyal", + title="{Wave and Equation Based Rate Control (WEBRC) Building Block}", + howpublished="RFC 3738 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3738", + pages="1--32", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3738.txt", + key="RFC 3738", + abstract={This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. This memo defines an Experimental Protocol for the Internet community.}, + keywords="congestion control, data delivery, multicast, ip, internet protocol", + doi="10.17487/RFC3738", + } + +@misc{rfc3739, + author="S. Santesson and M. Nystrom and T. Polk", + title="{Internet X.509 Public Key Infrastructure: Qualified Certificates Profile}", + howpublished="RFC 3739 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3739", + pages="1--34", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3739.txt", + key="RFC 3739", + abstract={This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]}, + keywords="syntax", + doi="10.17487/RFC3739", + } + +@misc{rfc3740, + author="T. Hardjono and B. Weis", + title="{The Multicast Group Security Architecture}", + howpublished="RFC 3740 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3740", + pages="1--26", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3740.txt", + key="RFC 3740", + abstract={This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. This memo provides information for the Internet community.}, + keywords="data packets", + doi="10.17487/RFC3740", + } + +@misc{rfc3741, + author="J. Boyer and D. {Eastlake 3rd} and J. Reagle", + title="{Exclusive XML Canonicalization, Version 1.0}", + howpublished="RFC 3741 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3741", + pages="1--16", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3741.txt", + key="RFC 3741", + abstract={Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the ``xml:'' namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. This memo provides information for the Internet community.}, + keywords="extensible markup language, namespace", + doi="10.17487/RFC3741", + } + +@misc{rfc3742, + author="S. Floyd", + title="{Limited Slow-Start for TCP with Large Congestion Windows}", + howpublished="RFC 3742 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3742", + pages="1--7", + year=2004, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3742.txt", + key="RFC 3742", + abstract={This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Intern et community.}, + keywords="transmission control protocol", + doi="10.17487/RFC3742", + } + +@misc{rfc3743, + author="K. Konishi and K. Huang and H. Qian and Y. Ko", + title="{Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean}", + howpublished="RFC 3743 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3743", + pages="1--33", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3743.txt", + key="RFC 3743", + abstract={Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration. The IETF Standards for Internationalized Domain Names, known as ``IDNA'', focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Kor ean (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.}, + doi="10.17487/RFC3743", + } + +@misc{rfc3744, + author="G. Clemm and J. Reschke and E. Sedlar and J. Whitehead", + title="{Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol}", + howpublished="RFC 3744 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3744", + pages="1--72", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3744.txt", + key="RFC 3744", + abstract={This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3744", + } + +@misc{rfc3745, + author="D. Singer and R. Clark and D. Lee", + title="{MIME Type Registrations for JPEG 2000 (ISO/IEC 15444)}", + howpublished="RFC 3745 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3745", + pages="1--14", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3745.txt", + key="RFC 3745", + abstract={This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000 (Joint Photographic Experts Group). [STANDARDS-TRACK]}, + keywords="multipurpose internet mail extensions, joint photographic experts group", + doi="10.17487/RFC3745", + } + +@misc{rfc3746, + author="L. Yang and R. Dantu and T. Anderson and R. Gopal", + title="{Forwarding and Control Element Separation (ForCES) Framework}", + howpublished="RFC 3746 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3746", + pages="1--40", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3746.txt", + key="RFC 3746", + abstract={This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. This is memo provides information for the Internet community.}, + keywords="network elements", + doi="10.17487/RFC3746", + } + +@misc{rfc3747, + author="H. {Hazewinkel (Ed.)} and D. {Partain (Ed.)}", + title="{The Differentiated Services Configuration MIB}", + howpublished="RFC 3747 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3747", + pages="1--24", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3747.txt", + key="RFC 3747", + abstract={This memo describes a MIB module that provides a conceptual layer between high-level ``network-wide'' policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. [PROPOSED STANDARD]}, + keywords="management information base, diffserv", + doi="10.17487/RFC3747", + } + +@misc{rfc3748, + author="B. Aboba and L. Blunk and J. Vollbrecht and J. Carlson and H. {Levkowetz (Ed.)}", + title="{Extensible Authentication Protocol (EAP)}", + howpublished="RFC 3748 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3748", + pages="1--67", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5247, 7057", +url="https://www.rfc-editor.org/rfc/rfc3748.txt", + key="RFC 3748", + abstract={This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]}, + keywords="PPP-EAP, data link layers, ppp, point-to-point, ieee 802", + doi="10.17487/RFC3748", + } + +@misc{rfc3749, + author="S. Hollenbeck", + title="{Transport Layer Security Protocol Compression Methods}", + howpublished="RFC 3749 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3749", + pages="1--8", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8447", +url="https://www.rfc-editor.org/rfc/rfc3749.txt", + key="RFC 3749", + abstract={The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]}, + keywords="tls, lossless data compression, handshake protocol", + doi="10.17487/RFC3749", + } + +@misc{rfc3750, + author="C. Huitema and R. Austein and S. Satapati and R. van der Pol", + title="{Unmanaged Networks IPv6 Transition Scenarios}", + howpublished="RFC 3750 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3750", + pages="1--20", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3750.txt", + key="RFC 3750", + abstract={This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the ``unmanaged network'', which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. This memo provides information for the Internet community.}, + keywords="single subnet, gateway, isp, internet service provider", + doi="10.17487/RFC3750", + } + +@misc{rfc3751, + author="S. Bradner", + title="{Omniscience Protocol Requirements}", + howpublished="RFC 3751 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3751", + pages="1--9", + year=2004, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3751.txt", + key="RFC 3751", + abstract={There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. This memo provides information for the Internet community.}, + doi="10.17487/RFC3751", + } + +@misc{rfc3752, + author="A. Barbir and E. Burger and R. Chen and S. McHenry and H. Orman and R. Penno", + title="{Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios}", + howpublished="RFC 3752 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3752", + pages="1--14", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3752.txt", + key="RFC 3752", + abstract={This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This memo provides information for the Internet community.}, + keywords="application data services", + doi="10.17487/RFC3752", + } + +@misc{rfc3753, + author="J. {Manner (Ed.)} and M. {Kojo (Ed.)}", + title="{Mobility Related Terminology}", + howpublished="RFC 3753 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3753", + pages="1--36", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3753.txt", + key="RFC 3753", + abstract={There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. This memo provides information for the Internet community.}, + keywords="networks, ip, internet protocol", + doi="10.17487/RFC3753", + } + +@misc{rfc3754, + author="R. Bless and K. Wehrle", + title="{IP Multicast in Differentiated Services (DS) Networks}", + howpublished="RFC 3754 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3754", + pages="1--34", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3754.txt", + key="RFC 3754", + abstract={This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 (``An Architecture of Differentiated Services''). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. This memo provides information for the Internet community.}, + keywords="internet protocol", + doi="10.17487/RFC3754", + } + +@misc{rfc3755, + author="S. Weiler", + title="{Legacy Resolver Compatibility for Delegation Signer (DS)}", + howpublished="RFC 3755 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3755", + pages="1--9", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035, updated by RFCs 3757, 3845", +url="https://www.rfc-editor.org/rfc/rfc3755.txt", + key="RFC 3755", + abstract={As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS-TRACK]}, + keywords="dnssec, DNS Security, rr, resource record, DNS-SECEXT, dns, authentication, nsec, nextsecure", + doi="10.17487/RFC3755", + } + +@misc{rfc3756, + author="P. {Nikander (Ed.)} and J. Kempf and E. Nordmark", + title="{IPv6 Neighbor Discovery (ND) Trust Models and Threats}", + howpublished="RFC 3756 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3756", + pages="1--23", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3756.txt", + key="RFC 3756", + abstract={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.}, + keywords="authentication, security key management", + doi="10.17487/RFC3756", + } + +@misc{rfc3757, + author="O. Kolkman and J. Schlyter and E. Lewis", + title="{Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag}", + howpublished="RFC 3757 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3757", + pages="1--8", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035", +url="https://www.rfc-editor.org/rfc/rfc3757.txt", + key="RFC 3757", + abstract={With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. [STANDARDS-TRACK]}, + keywords="dnssec", + doi="10.17487/RFC3757", + } + +@misc{rfc3758, + author="R. Stewart and M. Ramalho and Q. Xie and M. Tuexen and P. Conrad", + title="{Stream Control Transmission Protocol (SCTP) Partial Reliability Extension}", + howpublished="RFC 3758 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3758", + pages="1--22", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3758.txt", + key="RFC 3758", + abstract={This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS-TRACK]}, + keywords="init, init ack, forward tsn", + doi="10.17487/RFC3758", + } + +@misc{rfc3759, + author="L-E. Jonsson", + title="{RObust Header Compression (ROHC): Terminology and Channel Mapping Examples}", + howpublished="RFC 3759 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3759", + pages="1--20", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3759.txt", + key="RFC 3759", + abstract={This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. This memo provides information for the Internet community.}, + keywords="encapsulating, security, payload, real-time, transport, protocol, user, datagram", + doi="10.17487/RFC3759", + } + +@misc{rfc3760, + author="D. Gustafson and M. Just and M. Nystrom", + title="{Securely Available Credentials (SACRED) - Credential Server Framework}", + howpublished="RFC 3760 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3760", + pages="1--22", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3760.txt", + key="RFC 3760", + abstract={As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. This memo provides information for the Internet community.}, + doi="10.17487/RFC3760", + } + +@misc{rfc3761, + author="P. Faltstrom and M. Mealling", + title="{The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)}", + howpublished="RFC 3761 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3761", + pages="1--18", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 6116, 6117", +url="https://www.rfc-editor.org/rfc/rfc3761.txt", + key="RFC 3761", + abstract={This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS-TRACK]}, + keywords="domain name system", + doi="10.17487/RFC3761", + } + +@misc{rfc3762, + author="O. Levin", + title="{Telephone Number Mapping (ENUM) Service Registration for H.323}", + howpublished="RFC 3762 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3762", + pages="1--5", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc3762.txt", + key="RFC 3762", + abstract={The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. [STANDARDS-TRACK]}, + keywords="multimedia, packet based network", + doi="10.17487/RFC3762", + } + +@misc{rfc3763, + author="S. Shalunov and B. Teitelbaum", + title="{One-way Active Measurement Protocol (OWAMP) Requirements}", + howpublished="RFC 3763 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3763", + pages="1--11", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3763.txt", + key="RFC 3763", + abstract={With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This memo provides information for the Internet community.}, + keywords="performance metrics, delay, unidirectional", + doi="10.17487/RFC3763", + } + +@misc{rfc3764, + author="J. Peterson", + title="{enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record}", + howpublished="RFC 3764 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3764", + pages="1--8", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc3764.txt", + key="RFC 3764", + abstract={This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. [STANDARDS-TRACK]}, + keywords="aor, electronic number", + doi="10.17487/RFC3764", + } + +@misc{rfc3765, + author="G. Huston", + title="{NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control}", + howpublished="RFC 3765 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3765", + pages="1--7", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3765.txt", + key="RFC 3765", + abstract={This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. This memo provides information for the Internet community.}, + keywords="peer connections, propagated", + doi="10.17487/RFC3765", + } + +@misc{rfc3766, + author="H. Orman and P. Hoffman", + title="{Determining Strengths For Public Keys Used For Exchanging Symmetric Keys}", + howpublished="RFC 3766 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3766", + pages="1--23", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3766.txt", + key="RFC 3766", + abstract={Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-sca le 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.}, + keywords="security, cryptography algorithms, integers", + doi="10.17487/RFC3766", + } + +@misc{rfc3767, + author="S. {Farrell (Ed.)}", + title="{Securely Available Credentials Protocol}", + howpublished="RFC 3767 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3767", + pages="1--25", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3767.txt", + key="RFC 3767", + abstract={This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS \#15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]}, + keywords="beep, blocks extensible exchange protocol, xml, extensible mark up language", + doi="10.17487/RFC3767", + } + +@misc{rfc3768, + author="R. {Hinden (Ed.)}", + title="{Virtual Router Redundancy Protocol (VRRP)}", + howpublished="RFC 3768 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3768", + pages="1--27", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5798", +url="https://www.rfc-editor.org/rfc/rfc3768.txt", + key="RFC 3768", + abstract={This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]}, + keywords="VRRP, vrrp, lan, local, area, network, ip, internet, protocol", + doi="10.17487/RFC3768", + } + +@misc{rfc3769, + author="S. Miyakawa and R. Droms", + title="{Requirements for IPv6 Prefix Delegation}", + howpublished="RFC 3769 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3769", + pages="1--6", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3769.txt", + key="RFC 3769", + abstract={This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or ``site''). This memo provides information for the Internet community.}, + keywords="internet protocol version 6", + doi="10.17487/RFC3769", + } + +@misc{rfc3770, + author="R. Housley and T. Moore", + title="{Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)}", + howpublished="RFC 3770 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3770", + pages="1--9", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4334", +url="https://www.rfc-editor.org/rfc/rfc3770.txt", + key="RFC 3770", + abstract={This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). [STANDARDS-TRACK]}, + keywords="ssid, system service identifiers, eap", + doi="10.17487/RFC3770", + } + +@misc{rfc3771, + author="R. Harrison and K. Zeilenga", + title="{The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message}", + howpublished="RFC 3771 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3771", + pages="1--8", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4511, 4510", +url="https://www.rfc-editor.org/rfc/rfc3771.txt", + key="RFC 3771", + abstract={This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. [STANDARDS-TRACK]}, + keywords="LDAPv3, LDAv3, x.500", + doi="10.17487/RFC3771", + } + +@misc{rfc3772, + author="J. Carlson and R. Winslow", + title="{Point-to-Point Protocol (PPP) Vendor Protocol}", + howpublished="RFC 3772 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3772", + pages="1--10", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3772.txt", + key="RFC 3772", + abstract={The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols. [STANDARDS-TRACK]}, + keywords="link control protocol, lcp", + doi="10.17487/RFC3772", + } + +@misc{rfc3773, + author="E. Candell", + title="{High-Level Requirements for Internet Voice Mail}", + howpublished="RFC 3773 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3773", + pages="1--9", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3773.txt", + key="RFC 3773", + abstract={This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2. This memo provides information for the Internet community.}, + keywords="ivm, internet voice messaging, voice profile for internet mail, vpim", + doi="10.17487/RFC3773", + } + +@misc{rfc3774, + author="E. {Davies (Ed.)}", + title="{IETF Problem Statement}", + howpublished="RFC 3774 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3774", + pages="1--22", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3774.txt", + key="RFC 3774", + abstract={This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. This memo provides information for the Internet community.}, + keywords="ietf, process, problem, analysis", + doi="10.17487/RFC3774", + } + +@misc{rfc3775, + author="D. Johnson and C. Perkins and J. Arkko", + title="{Mobility Support in IPv6}", + howpublished="RFC 3775 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3775", + pages="1--165", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6275", +url="https://www.rfc-editor.org/rfc/rfc3775.txt", + key="RFC 3775", + abstract={This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS-TRACK]}, + keywords="internet protocol, nodes", + doi="10.17487/RFC3775", + } + +@misc{rfc3776, + author="J. Arkko and V. Devarapalli and F. Dupont", + title="{Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents}", + howpublished="RFC 3776 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3776", + pages="1--40", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4877", +url="https://www.rfc-editor.org/rfc/rfc3776.txt", + key="RFC 3776", + abstract={Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. [STANDARDS-TRACK]}, + keywords="security, internet protocol", + doi="10.17487/RFC3776", + } + +@misc{rfc3777, + author="J. {Galvin (Ed.)}", + title="{IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}", + howpublished="RFC 3777 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3777", + pages="1--34", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7437, updated by RFCs 5078, 5633, 5680, 6859", +url="https://www.rfc-editor.org/rfc/rfc3777.txt", + key="RFC 3777", + abstract={The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet Architecture Board, Engineering Steering Group", + doi="10.17487/RFC3777", + } + +@misc{rfc3778, + author="E. Taft and J. Pravetz and S. Zilles and L. Masinter", + title="{The application/pdf Media Type}", + howpublished="RFC 3778 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3778", + pages="1--14", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8118", +url="https://www.rfc-editor.org/rfc/rfc3778.txt", + key="RFC 3778", + abstract={PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. This memo provides information for the Internet community.}, + keywords="portable document format, document exchange, digital signatures", + doi="10.17487/RFC3778", + } + +@misc{rfc3779, + author="C. Lynn and S. Kent and K. Seo", + title="{X.509 Extensions for IP Addresses and AS Identifiers}", + howpublished="RFC 3779 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3779", + pages="1--27", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3779.txt", + key="RFC 3779", + abstract={This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]}, + keywords="allocation, atrribute certificate, authorization, autonomous system number authorization, certificate, delegation, internet registry, ip address authorization, public key infrastructure, right-to-use, secure allocation", + doi="10.17487/RFC3779", + } + +@misc{rfc3780, + author="F. Strauss and J. Schoenwaelder", + title="{SMIng - Next Generation Structure of Management Information}", + howpublished="RFC 3780 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3780", + pages="1--64", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3780.txt", + key="RFC 3780", + abstract={This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. This memo defines an Experimental Protocol for the Internet community.}, + keywords="data definition language", + doi="10.17487/RFC3780", + } + +@misc{rfc3781, + author="F. Strauss and J. Schoenwaelder", + title="{Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 3781 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3781", + pages="1--49", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3781.txt", + key="RFC 3781", + abstract={SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. This memo defines an Experimental Protocol for the Internet community.}, + keywords="data definition language", + doi="10.17487/RFC3781", + } + +@misc{rfc3782, + author="S. Floyd and T. Henderson and A. Gurtov", + title="{The NewReno Modification to TCP's Fast Recovery Algorithm}", + howpublished="RFC 3782 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3782", + pages="1--19", + year=2004, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6582", +url="https://www.rfc-editor.org/rfc/rfc3782.txt", + key="RFC 3782", + abstract={The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined ``Careful'' and ``Less Careful'' variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named ``Careful'' variant as the basic version of NewReno TCP. [STANDARDS-TRACK]}, + keywords="Transmission, Control, Protocol", + doi="10.17487/RFC3782", + } + +@misc{rfc3783, + author="M. Chadalapaka and R. Elliott", + title="{Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI}", + howpublished="RFC 3783 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3783", + pages="1--14", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3783.txt", + key="RFC 3783", + abstract={Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the classic SCSI ``I\_T nexus'', which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. This memo provides information for the Internet community.}, + keywords="Internet Small Computer Systems Interface, iscsi", + doi="10.17487/RFC3783", + } + +@misc{rfc3784, + author="H. Smit and T. Li", + title="{Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)}", + howpublished="RFC 3784 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3784", + pages="1--13", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5305, updated by RFC 4205", +url="https://www.rfc-editor.org/rfc/rfc3784.txt", + key="RFC 3784", + abstract={This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This memo provides information for the Internet community.}, + keywords="link state protocol, lsp", + doi="10.17487/RFC3784", + } + +@misc{rfc3785, + author="F. Le Faucheur and R. Uppili and A. Vedrenne and P. Merckx and T. Telkamp", + title="{Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric}", + howpublished="RFC 3785 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3785", + pages="1--8", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3785.txt", + key="RFC 3785", + abstract={This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="link, bandwidth router", + doi="10.17487/RFC3785", + } + +@misc{rfc3786, + author="A. Hermelin and S. Previdi and M. Shand", + title="{Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit}", + howpublished="RFC 3786 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3786", + pages="1--14", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5311", +url="https://www.rfc-editor.org/rfc/rfc3786.txt", + key="RFC 3786", + abstract={This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. This memo provides information for the Internet community.}, + doi="10.17487/RFC3786", + } + +@misc{rfc3787, + author="J. {Parker (Ed.)}", + title="{Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)}", + howpublished="RFC 3787 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3787", + pages="1--11", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3787.txt", + key="RFC 3787", + abstract={This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. This memo provides information for the Internet community.}, + keywords="routing traffic", + doi="10.17487/RFC3787", + } + +@misc{rfc3788, + author="J. Loughney and M. {Tuexen (Ed.)} and J. Pastor-Balbas", + title="{Security Considerations for Signaling Transport (SIGTRAN) Protocols}", + howpublished="RFC 3788 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3788", + pages="1--13", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3788.txt", + key="RFC 3788", + abstract={This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3788", + } + +@misc{rfc3789, + author="P. Nesser and II and A. {Bergstrom (Ed.)}", + title="{Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents}", + howpublished="RFC 3789 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3789", + pages="1--10", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3789.txt", + key="RFC 3789", + abstract={This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. This memo provides information for the Internet community.}, + doi="10.17487/RFC3789", + } + +@misc{rfc3790, + author="C. {Mickles (Ed.)} and P. Nesser and II", + title="{Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents}", + howpublished="RFC 3790 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3790", + pages="1--49", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3790.txt", + key="RFC 3790", + abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.}, + doi="10.17487/RFC3790", + } + +@misc{rfc3791, + author="C. Olvera and P. Nesser and II", + title="{Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents}", + howpublished="RFC 3791 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3791", + pages="1--15", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3791.txt", + key="RFC 3791", + abstract={This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.}, + doi="10.17487/RFC3791", + } + +@misc{rfc3792, + author="P. Nesser and II and A. {Bergstrom (Ed.)}", + title="{Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents}", + howpublished="RFC 3792 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3792", + pages="1--25", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3792.txt", + key="RFC 3792", + abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.}, + doi="10.17487/RFC3792", + } + +@misc{rfc3793, + author="P. Nesser and II and A. {Bergstrom (Ed.)}", + title="{Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents}", + howpublished="RFC 3793 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3793", + pages="1--6", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3793.txt", + key="RFC 3793", + abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.}, + doi="10.17487/RFC3793", + } + +@misc{rfc3794, + author="P. Nesser and II and A. {Bergstrom (Ed.)}", + title="{Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents}", + howpublished="RFC 3794 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3794", + pages="1--31", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3794.txt", + key="RFC 3794", + abstract={This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.}, + doi="10.17487/RFC3794", + } + +@misc{rfc3795, + author="R. Sofia and P. Nesser and II", + title="{Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents}", + howpublished="RFC 3795 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3795", + pages="1--50", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3795.txt", + key="RFC 3795", + abstract={This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This memo provides information for the Internet community.}, + doi="10.17487/RFC3795", + } + +@misc{rfc3796, + author="P. Nesser and II and A. {Bergstrom (Ed.)}", + title="{Survey of IPv4 Addresses in Currently Deployed IETF Operations \& Management Area Standards Track and Experimental Documents}", + howpublished="RFC 3796 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3796", + pages="1--43", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3796.txt", + key="RFC 3796", + abstract={This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations \& 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.}, + doi="10.17487/RFC3796", + } + +@misc{rfc3797, + author="D. {Eastlake 3rd}", + title="{Publicly Verifiable Nominations Committee (NomCom) Random Selection}", + howpublished="RFC 3797 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3797", + pages="1--19", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3797.txt", + key="RFC 3797", + abstract={This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.}, + keywords="Internet Engineering Task Force, IETF", + doi="10.17487/RFC3797", + } + +@misc{rfc3798, + author="T. {Hansen (Ed.)} and G. {Vaudreuil (Ed.)}", + title="{Message Disposition Notification}", + howpublished="RFC 3798 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3798", + pages="1--30", + year=2004, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8098, updated by RFCs 5337, 6533", +url="https://www.rfc-editor.org/rfc/rfc3798.txt", + key="RFC 3798", + abstract={This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary ``LAN-based'' systems, and often referred to as ``read receipts,'' ``acknowledgements'', or ``receipt notifications.'' The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary ``LAN-based'' systems), the MDN protocol is designed to be us eful 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]}, + keywords="EMF-MDN, MDN, media-type, MIME, multipurpose internet mail extensions", + doi="10.17487/RFC3798", + } + +@misc{rfc3801, + author="G. Vaudreuil and G. Parsons", + title="{Voice Profile for Internet Mail - version 2 (VPIMv2)}", + howpublished="RFC 3801 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3801", + pages="1--55", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3801.txt", + key="RFC 3801", + abstract={This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems. This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM. [STANDARDS-TRACK]}, + keywords="MIME-VP2, vpim, messaging", + doi="10.17487/RFC3801", + } + +@misc{rfc3802, + author="G. Vaudreuil and G. Parsons", + title="{Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration}", + howpublished="RFC 3802 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3802", + pages="1--7", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3802.txt", + key="RFC 3802", + abstract={This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. [STANDARDS-TRACK]}, + keywords="MIME-ADPCM, multipurpose, internet, mail, extensions, audio", + doi="10.17487/RFC3802", + } + +@misc{rfc3803, + author="G. Vaudreuil and G. Parsons", + title="{Content Duration MIME Header Definition}", + howpublished="RFC 3803 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3803", + pages="1--5", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3803.txt", + key="RFC 3803", + abstract={This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS-TRACK]}, + keywords="CONT-DUR, multipurpose internet mail extensions, time, media", + doi="10.17487/RFC3803", + } + +@misc{rfc3804, + author="G. Parsons", + title="{Voice Profile for Internet Mail (VPIM) Addressing}", + howpublished="RFC 3804 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3804", + pages="1--15", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3804.txt", + key="RFC 3804", + abstract={This document lists the various Voice Profile for Internet Mail (VPIM) email address formats that are currently in common use and defines several new address formats for special case usage. Requirements are imposed on the formats of addresses used in VPIM submission mode. [STANDARDS-TRACK]}, + keywords="formats", + doi="10.17487/RFC3804", + } + +@misc{rfc3805, + author="R. Bergman and H. Lewis and I. McDonald", + title="{Printer MIB v2}", + howpublished="RFC 3805 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3805", + pages="1--171", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3805.txt", + key="RFC 3805", + abstract={This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. [STANDARDS-TRACK]}, + keywords="Print-MIB, Management Information Base, snmp, management", + doi="10.17487/RFC3805", + } + +@misc{rfc3806, + author="R. Bergman and H. Lewis and I. McDonald", + title="{Printer Finishing MIB}", + howpublished="RFC 3806 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3806", + pages="1--53", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3806.txt", + key="RFC 3806", + abstract={This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a Printer System. This memo provides information for the Internet community.}, + keywords="finisher, snmp", + doi="10.17487/RFC3806", + } + +@misc{rfc3807, + author="E. Weilandt and N. Khanchandani and S. Rao", + title="{V5.2-User Adaptation Layer (V5UA)}", + howpublished="RFC 3807 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3807", + pages="1--24", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3807.txt", + key="RFC 3807", + abstract={This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS-TRACK]}, + keywords="v5, v5.1, v5.2, backhauling, imap, sctp, isdn, access network, c-path, c-channel, efa, envelope function address, lapv5, pstn, v5ptm, mgc, gateway controller, gateway", + doi="10.17487/RFC3807", + } + +@misc{rfc3808, + author="I. McDonald", + title="{IANA Charset MIB}", + howpublished="RFC 3808 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3808", + pages="1--14", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3808.txt", + key="RFC 3808", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978). This memo provides information for the Internet community.}, + keywords="management information base, IANACharset", + doi="10.17487/RFC3808", + } + +@misc{rfc3809, + author="A. {Nagarajan (Ed.)}", + title="{Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)}", + howpublished="RFC 3809 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3809", + pages="1--25", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3809.txt", + key="RFC 3809", + abstract={This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. This memo provides information for the Internet community.}, + keywords="service engineering", + doi="10.17487/RFC3809", + } + +@misc{rfc3810, + author="R. {Vida (Ed.)} and L. {Costa (Ed.)}", + title="{Multicast Listener Discovery Version 2 (MLDv2) for IPv6}", + howpublished="RFC 3810 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3810", + pages="1--62", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4604", +url="https://www.rfc-editor.org/rfc/rfc3810.txt", + key="RFC 3810", + abstract={This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]}, + keywords="ssm, source filtering, igmp, group management, mld", + doi="10.17487/RFC3810", + } + +@misc{rfc3811, + author="T. {Nadeau (Ed.)} and J. {Cucchiara (Ed.)}", + title="{Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management}", + howpublished="RFC 3811 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3811", + pages="1--20", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7274", +url="https://www.rfc-editor.org/rfc/rfc3811.txt", + key="RFC 3811", + abstract={This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]}, + keywords="management information base", + doi="10.17487/RFC3811", + } + +@misc{rfc3812, + author="C. Srinivasan and A. Viswanathan and T. Nadeau", + title="{Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)}", + howpublished="RFC 3812 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3812", + pages="1--68", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3812.txt", + key="RFC 3812", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3812", + } + +@misc{rfc3813, + author="C. Srinivasan and A. Viswanathan and T. Nadeau", + title="{Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)}", + howpublished="RFC 3813 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3813", + pages="1--60", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3813.txt", + key="RFC 3813", + abstract={This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS-TRACK]}, + doi="10.17487/RFC3813", + } + +@misc{rfc3814, + author="T. Nadeau and C. Srinivasan and A. Viswanathan", + title="{Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)}", + howpublished="RFC 3814 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3814", + pages="1--42", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3814.txt", + key="RFC 3814", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3814", + } + +@misc{rfc3815, + author="J. Cucchiara and H. Sjostrand and J. Luciani", + title="{Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)}", + howpublished="RFC 3815 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3815", + pages="1--106", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3815.txt", + key="RFC 3815", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3815", + } + +@misc{rfc3816, + author="J. Quittek and M. Stiemerling and H. Hartenstein", + title="{Definitions of Managed Objects for RObust Header Compression (ROHC)}", + howpublished="RFC 3816 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3816", + pages="1--53", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3816.txt", + key="RFC 3816", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS-TRACK]}, + keywords="mib, management information base", + doi="10.17487/RFC3816", + } + +@misc{rfc3817, + author="W. Townsley and R. da Silva", + title="{Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)}", + howpublished="RFC 3817 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3817", + pages="1--17", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3817.txt", + key="RFC 3817", + abstract={The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. This memo provides information for the Internet community.}, + keywords="point-to-point", + doi="10.17487/RFC3817", + } + +@misc{rfc3818, + author="V. Schryver", + title="{IANA Considerations for the Point-to-Point Protocol (PPP)}", + howpublished="RFC 3818 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3818", + pages="1--4", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3818.txt", + key="RFC 3818", + abstract={The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to ``actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value.'' In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be ``first come first served.'' This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC3818", + } + +@misc{rfc3819, + author="P. {Karn (Ed.)} and C. Bormann and G. Fairhurst and D. Grossman and R. Ludwig and J. Mahdavi and G. Montenegro and J. Touch and L. Wood", + title="{Advice for Internet Subnetwork Designers}", + howpublished="RFC 3819 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3819", + pages="1--60", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3819.txt", + key="RFC 3819", + abstract={This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="digital communication equipment, link-layer protocols, packet-switched local networks", + doi="10.17487/RFC3819", + } + +@misc{rfc3820, + author="S. Tuecke and V. Welch and D. Engert and L. Pearlman and M. Thompson", + title="{Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile}", + howpublished="RFC 3820 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3820", + pages="1--37", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3820.txt", + key="RFC 3820", + abstract={This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS-TRACK]}, + keywords="authentication, security credentials, restricted delegation, single-signon, delegation of rights", + doi="10.17487/RFC3820", + } + +@misc{rfc3821, + author="M. Rajagopal and E. Rodriguez and R. Weber", + title="{Fibre Channel Over TCP/IP (FCIP)}", + howpublished="RFC 3821 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3821", + pages="1--74", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc3821.txt", + key="RFC 3821", + abstract={Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. [STANDARDS-TRACK]}, + keywords="storage area networks, IP-based networks, unified storage area network", + doi="10.17487/RFC3821", + } + +@misc{rfc3822, + author="D. Peterson", + title="{Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)}", + howpublished="RFC 3822 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3822", + pages="1--11", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc3822.txt", + key="RFC 3822", + abstract={This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS-TRACK]}, + keywords="dynamic discovery", + doi="10.17487/RFC3822", + } + +@misc{rfc3823, + author="B. Kovitz", + title="{MIME Media Type for the Systems Biology Markup Language (SBML)}", + howpublished="RFC 3823 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3823", + pages="1--8", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3823.txt", + key="RFC 3823", + abstract={This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. This memo provides information for the Internet community.}, + keywords="sub-type application/sbml+xml, systems biology community", + doi="10.17487/RFC3823", + } + +@misc{rfc3824, + author="J. Peterson and H. Liu and J. Yu and B. Campbell", + title="{Using E.164 numbers with the Session Initiation Protocol (SIP)}", + howpublished="RFC 3824 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3824", + pages="1--16", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3824.txt", + key="RFC 3824", + abstract={There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This memo provides information for the Internet community.}, + keywords="telephone records, applications", + doi="10.17487/RFC3824", + } + +@misc{rfc3825, + author="J. Polk and J. Schnizlein and M. Linsner", + title="{Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information}", + howpublished="RFC 3825 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3825", + pages="1--15", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6225", +url="https://www.rfc-editor.org/rfc/rfc3825.txt", + key="RFC 3825", + abstract={This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. [STANDARDS-TRACK]}, + keywords="dhcp, lci, geographic location", + doi="10.17487/RFC3825", + } + +@misc{rfc3826, + author="U. Blumenthal and F. Maino and K. McCloghrie", + title="{The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model}", + howpublished="RFC 3826 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3826", + pages="1--16", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3826.txt", + key="RFC 3826", + abstract={This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]}, + keywords="management information base, simple network management protocol", + doi="10.17487/RFC3826", + } + +@misc{rfc3827, + author="K. Sarcar", + title="{Additional Snoop Datalink Types}", + howpublished="RFC 3827 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3827", + pages="1--4", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3827.txt", + key="RFC 3827", + abstract={The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. This memo provides information for the Internet community.}, + doi="10.17487/RFC3827", + } + +@misc{rfc3828, + author="L-A. Larzon and M. Degermark and S. Pink and L-E. {Jonsson (Ed.)} and G. {Fairhurst (Ed.)}", + title="{The Lightweight User Datagram Protocol (UDP-Lite)}", + howpublished="RFC 3828 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3828", + pages="1--12", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6335", +url="https://www.rfc-editor.org/rfc/rfc3828.txt", + key="RFC 3828", + abstract={This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3828", + } + +@misc{rfc3829, + author="R. Weltman and M. Smith and M. Wahl", + title="{Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls}", + howpublished="RFC 3829 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3829", + pages="1--6", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3829.txt", + key="RFC 3829", + abstract={This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. This memo provides information for the Internet community.}, + keywords="bind operation", + doi="10.17487/RFC3829", + } + +@misc{rfc3830, + author="J. Arkko and E. Carrara and F. Lindholm and M. Naslund and K. Norrman", + title="{MIKEY: Multimedia Internet KEYing}", + howpublished="RFC 3830 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3830", + pages="1--66", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4738, 6309", +url="https://www.rfc-editor.org/rfc/rfc3830.txt", + key="RFC 3830", + abstract={This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK]}, + keywords="key management scheme, real-time applications", + doi="10.17487/RFC3830", + } + +@misc{rfc3831, + author="C. DeSanti", + title="{Transmission of IPv6 Packets over Fibre Channel}", + howpublished="RFC 3831 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3831", + pages="1--24", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4338", +url="https://www.rfc-editor.org/rfc/rfc3831.txt", + key="RFC 3831", + abstract={This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. [STANDARDS-TRACK]}, + keywords="addresses, link-local, internet protocol", + doi="10.17487/RFC3831", + } + +@misc{rfc3832, + author="W. Zhao and H. Schulzrinne and E. Guttman and C. Bisdikian and W. Jerome", + title="{Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV}", + howpublished="RFC 3832 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3832", + pages="1--8", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3832.txt", + key="RFC 3832", + abstract={Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. This memo defines an Experimental Protocol for the Internet community.}, + keywords="DNS-SRV, domain, name, system, resource, record", + doi="10.17487/RFC3832", + } + +@misc{rfc3833, + author="D. Atkins and R. Austein", + title="{Threat Analysis of the Domain Name System (DNS)}", + howpublished="RFC 3833 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3833", + pages="1--16", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3833.txt", + key="RFC 3833", + abstract={Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community.}, + keywords="data disclosure, security, authentication", + doi="10.17487/RFC3833", + } + +@misc{rfc3834, + author="K. Moore", + title="{Recommendations for Automatic Responses to Electronic Mail}", + howpublished="RFC 3834 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3834", + pages="1--22", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5436", +url="https://www.rfc-editor.org/rfc/rfc3834.txt", + key="RFC 3834", + abstract={This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including ``out of the office'' or ``vacation'' response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS-TRACK]}, + keywords="automatic mail responders", + doi="10.17487/RFC3834", + } + +@misc{rfc3835, + author="A. Barbir and R. Penno and R. Chen and M. Hofmann and H. Orman", + title="{An Architecture for Open Pluggable Edge Services (OPES)}", + howpublished="RFC 3835 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3835", + pages="1--17", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3835.txt", + key="RFC 3835", + abstract={This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. This memo provides information for the Internet community.}, + keywords="application service, data stream service, data consumer, data dispatcher architecture", + doi="10.17487/RFC3835", + } + +@misc{rfc3836, + author="A. Beck and M. Hofmann and H. Orman and R. Penno and A. Terzis", + title="{Requirements for Open Pluggable Edge Services (OPES) Callout Protocols}", + howpublished="RFC 3836 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3836", + pages="1--13", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3836.txt", + key="RFC 3836", + abstract={This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. This memo provides information for the Internet community.}, + keywords="callout protocol, remote execution, OPES services", + doi="10.17487/RFC3836", + } + +@misc{rfc3837, + author="A. Barbir and O. Batuner and B. Srinivas and M. Hofmann and H. Orman", + title="{Security Threats and Risks for Open Pluggable Edge Services (OPES)}", + howpublished="RFC 3837 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3837", + pages="1--14", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3837.txt", + key="RFC 3837", + abstract={The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. This memo provides information for the Internet community.}, + keywords="threat discovery, threat analysis", + doi="10.17487/RFC3837", + } + +@misc{rfc3838, + author="A. Barbir and O. Batuner and A. Beck and T. Chan and H. Orman", + title="{Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)}", + howpublished="RFC 3838 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3838", + pages="1--17", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3838.txt", + key="RFC 3838", + abstract={This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. This memo provides information for the Internet community.}, + keywords="opes flow", + doi="10.17487/RFC3838", + } + +@misc{rfc3839, + author="R. Castagno and D. Singer", + title="{MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files}", + howpublished="RFC 3839 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3839", + pages="1--7", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6381", +url="https://www.rfc-editor.org/rfc/rfc3839.txt", + key="RFC 3839", + abstract={This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]}, + keywords="standard MIME types, 3GPP multimedia file format, ISO Media File Format", + doi="10.17487/RFC3839", + } + +@misc{rfc3840, + author="J. Rosenberg and H. Schulzrinne and P. Kyzivat", + title="{Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)}", + howpublished="RFC 3840 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3840", + pages="1--36", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3840.txt", + key="RFC 3840", + abstract={This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]}, + keywords="ua, contact header field", + doi="10.17487/RFC3840", + } + +@misc{rfc3841, + author="J. Rosenberg and H. Schulzrinne and P. Kyzivat", + title="{Caller Preferences for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3841 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3841", + pages="1--26", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3841.txt", + key="RFC 3841", + abstract={This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. [STANDARDS-TRACK]}, + keywords="Uniform Resource Identifiers, URI, Accept-Contact, Reject-Contact, Request-Disposition", + doi="10.17487/RFC3841", + } + +@misc{rfc3842, + author="R. Mahy", + title="{A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3842 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3842", + pages="1--19", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3842.txt", + key="RFC 3842", + abstract={This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK]}, + keywords="message waiting status, message summary", + doi="10.17487/RFC3842", + } + +@misc{rfc3843, + author="L-E. Jonsson and G. Pelletier", + title="{RObust Header Compression (ROHC): A Compression Profile for IP}", + howpublished="RFC 3843 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3843", + pages="1--16", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4815", +url="https://www.rfc-editor.org/rfc/rfc3843.txt", + key="RFC 3843", + abstract={The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS-TRACK]}, + keywords="compression protocols", + doi="10.17487/RFC3843", + } + +@misc{rfc3844, + author="E. {Davies (Ed.)} and J. {Hofmann (Ed.)}", + title="{IETF Problem Resolution Process}", + howpublished="RFC 3844 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3844", + pages="1--20", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3844.txt", + key="RFC 3844", + abstract={This Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short-term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. This memo provides information for the Internet community.}, + keywords="ietf, process, problem, analysis", + doi="10.17487/RFC3844", + } + +@misc{rfc3845, + author="J. {Schlyter (Ed.)}", + title="{DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format}", + howpublished="RFC 3845 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3845", + pages="1--7", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 4033, 4034, 4035", +url="https://www.rfc-editor.org/rfc/rfc3845.txt", + key="RFC 3845", + abstract={This document redefines the wire format of the ``Type Bit Map'' field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS-TRACK]}, + keywords="dnssec, DNS Security, rr, resource record, DNS-SECEXT, dns, authentication, nsec, nextsecure", + doi="10.17487/RFC3845", + } + +@misc{rfc3846, + author="F. Johansson and T. Johansson", + title="{Mobile IPv4 Extension for Carrying Network Access Identifiers}", + howpublished="RFC 3846 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3846", + pages="1--8", + year=2004, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3846.txt", + key="RFC 3846", + abstract={When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. [STANDARDS-TRACK]}, + keywords="nai, internet protocol, home aaa server, ha server, home agents", + doi="10.17487/RFC3846", + } + +@misc{rfc3847, + author="M. Shand and L. Ginsberg", + title="{Restart Signaling for Intermediate System to Intermediate System (IS-IS)}", + howpublished="RFC 3847 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3847", + pages="1--21", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5306", +url="https://www.rfc-editor.org/rfc/rfc3847.txt", + key="RFC 3847", + abstract={This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This memo provides information for the Internet community.}, + keywords="LSP database synchronization, transient routing disruption, database synchronization", + doi="10.17487/RFC3847", + } + +@misc{rfc3848, + author="C. Newman", + title="{ESMTP and LMTP Transmission Types Registration}", + howpublished="RFC 3848 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3848", + pages="1--4", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3848.txt", + key="RFC 3848", + abstract={This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the ``with'' clause of a Received header in an Internet message. [STANDARDS-TRACK]}, + keywords="smtp, simple mail transfer protocol", + doi="10.17487/RFC3848", + } + +@misc{rfc3849, + author="G. Huston and A. Lord and P. Smith", + title="{IPv6 Address Prefix Reserved for Documentation}", + howpublished="RFC 3849 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3849", + pages="1--4", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3849.txt", + key="RFC 3849", + abstract={To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community.}, + keywords="unicast, site-local, link-local", + doi="10.17487/RFC3849", + } + +@misc{rfc3850, + author="B. {Ramsdell (Ed.)}", + title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling}", + howpublished="RFC 3850 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3850", + pages="1--16", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5750", +url="https://www.rfc-editor.org/rfc/rfc3850.txt", + key="RFC 3850", + abstract={This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. [STANDARDS-TRACK]}, + keywords="x.509, encryption, certificate, multipurpose, internet, mail, extensions, secure", + doi="10.17487/RFC3850", + } + +@misc{rfc3851, + author="B. {Ramsdell (Ed.)}", + title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification}", + howpublished="RFC 3851 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3851", + pages="1--36", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5751", +url="https://www.rfc-editor.org/rfc/rfc3851.txt", + key="RFC 3851", + abstract={This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS-TRACK]}, + keywords="secure, multipurpose, internet, mail, extensions, encryption", + doi="10.17487/RFC3851", + } + +@misc{rfc3852, + author="R. Housley", + title="{Cryptographic Message Syntax (CMS)}", + howpublished="RFC 3852 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3852", + pages="1--56", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5652, updated by RFCs 4853, 5083", +url="https://www.rfc-editor.org/rfc/rfc3852.txt", + key="RFC 3852", + abstract={This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]}, + keywords="digitally sign, authenticate, encrypt, arbitrary message content", + doi="10.17487/RFC3852", + } + +@misc{rfc3853, + author="J. Peterson", + title="{S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3853 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3853", + pages="1--6", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3853.txt", + key="RFC 3853", + abstract={RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS-TRACK]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC3853", + } + +@misc{rfc3854, + author="P. Hoffman and C. Bonatti and A. Eggen", + title="{Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)}", + howpublished="RFC 3854 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3854", + pages="1--15", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3854.txt", + key="RFC 3854", + abstract={This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME). [STANDARDS-TRACK]}, + keywords="encryption, cryptographic signature", + doi="10.17487/RFC3854", + } + +@misc{rfc3855, + author="P. Hoffman and C. Bonatti", + title="{Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400}", + howpublished="RFC 3855 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3855", + pages="1--12", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3855.txt", + key="RFC 3855", + abstract={This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. [STANDARDS-TRACK]}, + keywords="cms, cryptographic message syntax message", + doi="10.17487/RFC3855", + } + +@misc{rfc3856, + author="J. Rosenberg", + title="{A Presence Event Package for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3856 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3856", + pages="1--27", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3856.txt", + key="RFC 3856", + abstract={This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to ``on-line'' and ``off-line'' indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]}, + keywords="subscription notification", + doi="10.17487/RFC3856", + } + +@misc{rfc3857, + author="J. Rosenberg", + title="{A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3857 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3857", + pages="1--20", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3857.txt", + key="RFC 3857", + abstract={This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. [STANDARDS-TRACK]}, + doi="10.17487/RFC3857", + } + +@misc{rfc3858, + author="J. Rosenberg", + title="{An Extensible Markup Language (XML) Based Format for Watcher Information}", + howpublished="RFC 3858 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3858", + pages="1--13", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3858.txt", + key="RFC 3858", + abstract={Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state. [STANDARDS-TRACK]}, + keywords="Extensible Markup Language, xml", + doi="10.17487/RFC3858", + } + +@misc{rfc3859, + author="J. Peterson", + title="{Common Profile for Presence (CPP)}", + howpublished="RFC 3859 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3859", + pages="1--15", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3859.txt", + key="RFC 3859", + abstract={At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. [STANDARDS-TRACK]}, + keywords="data formats, semantics, instant messaging", + doi="10.17487/RFC3859", + } + +@misc{rfc3860, + author="J. Peterson", + title="{Common Profile for Instant Messaging (CPIM)}", + howpublished="RFC 3860 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3860", + pages="1--13", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3860.txt", + key="RFC 3860", + abstract={At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK]}, + keywords="data formats, semantics, instant messaging", + doi="10.17487/RFC3860", + } + +@misc{rfc3861, + author="J. Peterson", + title="{Address Resolution for Instant Messaging and Presence}", + howpublished="RFC 3861 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3861", + pages="1--8", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3861.txt", + key="RFC 3861", + abstract={Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS-TRACK]}, + keywords="uri, schemes, universal resource identifier, impp, instant messaging and presence protocol, presentity, instant inbox", + doi="10.17487/RFC3861", + } + +@misc{rfc3862, + author="G. Klyne and D. Atkins", + title="{Common Presence and Instant Messaging (CPIM): Message Format}", + howpublished="RFC 3862 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3862", + pages="1--30", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3862.txt", + key="RFC 3862", + abstract={This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS-TRACK]}, + keywords="instant messaging and presence protocol, message/cpim", + doi="10.17487/RFC3862", + } + +@misc{rfc3863, + author="H. Sugano and S. Fujimoto and G. Klyne and A. Bateman and W. Carr and J. Peterson", + title="{Presence Information Data Format (PIDF)}", + howpublished="RFC 3863 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3863", + pages="1--28", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3863.txt", + key="RFC 3863", + abstract={This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type ``application/pidf+xml'' to represent the XML MIME entity for PIDF. [STANDARDS-TRACK]}, + keywords="instant messaging and presence protocol, cpp, common profile for presence, presence data format, application/pidf+xml", + doi="10.17487/RFC3863", + } + +@misc{rfc3864, + author="G. Klyne and M. Nottingham and J. Mogul", + title="{Registration Procedures for Message Header Fields}", + howpublished="RFC 3864 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3864", + pages="1--17", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3864.txt", + key="RFC 3864", + abstract={This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="Internet mail, HTTP, Netnews", + doi="10.17487/RFC3864", + } + +@misc{rfc3865, + author="C. Malamud", + title="{A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension}", + howpublished="RFC 3865 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3865", + pages="1--19", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3865.txt", + key="RFC 3865", + abstract={This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world ``No Soliciting'' sign. In addition to the service extension, a new message header and extensions to the existing ``received'' message header are described. [STANDARDS-TRACK]}, + keywords="unsolicited bulk email, ube, no soliciting, solicitation class keywords, solicitation mail header, trace fields", + doi="10.17487/RFC3865", + } + +@misc{rfc3866, + author="K. {Zeilenga (Ed.)}", + title="{Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)}", + howpublished="RFC 3866 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3866", + pages="1--15", + year=2004, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3866.txt", + key="RFC 3866", + abstract={It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). [STANDARDS-TRACK]}, + keywords="lightweight, directory, access, protocol, servers", + doi="10.17487/RFC3866", + } + +@misc{rfc3867, + author="Y. Kawatsura and M. Hiroya and H. Beykirch", + title="{Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP)}", + howpublished="RFC 3867 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3867", + pages="1--106", + year=2004, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3867.txt", + key="RFC 3867", + abstract={The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores. Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. This memo provides information for the Internet community.}, + keywords="modules, data format exchange", + doi="10.17487/RFC3867", + } + +@misc{rfc3868, + author="J. {Loughney (Ed.)} and G. Sidebottom and L. Coene and G. Verwimp and J. Keller and B. Bidulock", + title="{Signalling Connection Control Part User Adaptation Layer (SUA)}", + howpublished="RFC 3868 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3868", + pages="1--131", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3868.txt", + key="RFC 3868", + abstract={This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. [STANDARDS-TRACK]}, + keywords="sctp, stream control transmission protocol, modular, symmetric, signalling gateway, signalling endpoint architecture", + doi="10.17487/RFC3868", + } + +@misc{rfc3869, + author="R. {Atkinson (Ed.)} and S. {Floyd (Ed.)} and Internet Architecture Board", + title="{IAB Concerns and Recommendations Regarding Internet Research and Evolution}", + howpublished="RFC 3869 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3869", + pages="1--30", + year=2004, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3869.txt", + key="RFC 3869", + abstract={This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. This memo provides information for the Internet community.}, + keywords="internet architecture board, internet infrastructure, non-commercial funding", + doi="10.17487/RFC3869", + } + +@misc{rfc3870, + author="A. Swartz", + title="{application/rdf+xml Media Type Registration}", + howpublished="RFC 3870 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3870", + pages="1--8", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3870.txt", + key="RFC 3870", + abstract={This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. This memo provides information for the Internet community.}, + keywords="xml, extensible markup language, mime, multipurpose internet mail extensions, rdf, resource description framework", + doi="10.17487/RFC3870", + } + +@misc{rfc3871, + author="G. {Jones (Ed.)}", + title="{Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure}", + howpublished="RFC 3871 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3871", + pages="1--81", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3871.txt", + key="RFC 3871", + abstract={This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying ``profiles'', which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. This memo provides information for the Internet community.}, + doi="10.17487/RFC3871", + } + +@misc{rfc3872, + author="D. Zinman and D. Walker and J. Jiang", + title="{Management Information Base for Telephony Routing over IP (TRIP)}", + howpublished="RFC 3872 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3872", + pages="1--53", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3872.txt", + key="RFC 3872", + abstract={This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. [STANDARDS-TRACK]}, + keywords="mib", + doi="10.17487/RFC3872", + } + +@misc{rfc3873, + author="J. Pastor and M. Belinchon", + title="{Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)}", + howpublished="RFC 3873 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3873", + pages="1--46", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3873.txt", + key="RFC 3873", + abstract={The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications. 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]}, + keywords="", + doi="10.17487/RFC3873", + } + +@misc{rfc3874, + author="R. Housley", + title="{A 224-bit One-way Hash Function: SHA-224}", + howpublished="RFC 3874 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3874", + pages="1--6", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3874.txt", + key="RFC 3874", + abstract={This document specifies a 224-bit one-way hash function, called SHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. This memo provides information for the Internet community.}, + keywords="secure standard", + doi="10.17487/RFC3874", + } + +@misc{rfc3875, + author="D. Robinson and K. Coar", + title="{The Common Gateway Interface (CGI) Version 1.1}", + howpublished="RFC 3875 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3875", + pages="1--36", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3875.txt", + key="RFC 3875", + abstract={The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. 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.}, + keywords="www, world wide web", + doi="10.17487/RFC3875", + } + +@misc{rfc3876, + author="D. Chadwick and S. Mullan", + title="{Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)}", + howpublished="RFC 3876 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3876", + pages="1--12", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3876.txt", + key="RFC 3876", + abstract={This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a ``values return'' filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. [STANDARDS-TRACK]}, + keywords="attribute, filter", + doi="10.17487/RFC3876", + } + +@misc{rfc3877, + author="S. Chisholm and D. Romascanu", + title="{Alarm Management Information Base (MIB)}", + howpublished="RFC 3877 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3877", + pages="1--75", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3877.txt", + key="RFC 3877", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. [STANDARDS-TRACK]}, + keywords="alarm mib, iana-itu-alarm-tc-mib, itu-alarm-tc-mib, itu-alarm-mib", + doi="10.17487/RFC3877", + } + +@misc{rfc3878, + author="H. Lam and A. Huynh and D. Perkins", + title="{Alarm Reporting Control Management Information Base (MIB)}", + howpublished="RFC 3878 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3878", + pages="1--16", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3878.txt", + key="RFC 3878", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. [STANDARDS-TRACK]}, + keywords="alarm condition, probably cause", + doi="10.17487/RFC3878", + } + +@misc{rfc3879, + author="C. Huitema and B. Carpenter", + title="{Deprecating Site Local Addresses}", + howpublished="RFC 3879 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3879", + pages="1--10", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3879.txt", + key="RFC 3879", + abstract={This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS-TRACK]}, + keywords="ipv6, architecture", + doi="10.17487/RFC3879", + } + +@misc{rfc3880, + author="J. Lennox and X. Wu and H. Schulzrinne", + title="{Call Processing Language (CPL): A Language for User Control of Internet Telephony Services}", + howpublished="RFC 3880 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3880", + pages="1--74", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3880.txt", + key="RFC 3880", + abstract={This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3880", + } + +@misc{rfc3881, + author="G. Marshall", + title="{Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications}", + howpublished="RFC 3881 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3881", + pages="1--47", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3881.txt", + key="RFC 3881", + abstract={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.}, + doi="10.17487/RFC3881", + } + +@misc{rfc3882, + author="D. Turk", + title="{Configuring BGP to Block Denial-of-Service Attacks}", + howpublished="RFC 3882 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3882", + pages="1--8", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3882.txt", + key="RFC 3882", + abstract={This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community.}, + keywords="dos, border gateway protocol", + doi="10.17487/RFC3882", + } + +@misc{rfc3883, + author="S. Rao and A. Zinin and A. Roy", + title="{Detecting Inactive Neighbors over OSPF Demand Circuits (DC)}", + howpublished="RFC 3883 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3883", + pages="1--6", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3883.txt", + key="RFC 3883", + abstract={OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called ``neighbor probing'' to address the above problem. [STANDARDS-TRACK]}, + keywords="OSPF-DC, Open Shortest Path First", + doi="10.17487/RFC3883", + } + +@misc{rfc3884, + author="J. Touch and L. Eggert and Y. Wang", + title="{Use of IPsec Transport Mode for Dynamic Routing}", + howpublished="RFC 3884 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3884", + pages="1--25", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3884.txt", + key="RFC 3884", + abstract={IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPse c 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.}, + doi="10.17487/RFC3884", + } + +@misc{rfc3885, + author="E. Allman and T. Hansen", + title="{SMTP Service Extension for Message Tracking}", + howpublished="RFC 3885 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3885", + pages="1--9", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3885.txt", + key="RFC 3885", + abstract={This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]}, + keywords="simple mail transfer protocol", + doi="10.17487/RFC3885", + } + +@misc{rfc3886, + author="E. Allman", + title="{An Extensible Message Format for Message Tracking Responses}", + howpublished="RFC 3886 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3886", + pages="1--11", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3886.txt", + key="RFC 3886", + abstract={Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. 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]}, + keywords="Delivery Status Notifications, DSN, Message Disposition Notifications, MDN", + doi="10.17487/RFC3886", + } + +@misc{rfc3887, + author="T. Hansen", + title="{Message Tracking Query Protocol}", + howpublished="RFC 3887 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3887", + pages="1--23", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3887.txt", + key="RFC 3887", + abstract={Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS-TRACK]}, + keywords="mtqp, ESMTP", + doi="10.17487/RFC3887", + } + +@misc{rfc3888, + author="T. Hansen", + title="{Message Tracking Model and Requirements}", + howpublished="RFC 3888 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3888", + pages="1--11", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3888.txt", + key="RFC 3888", + abstract={Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. This memo provides information for the Internet community.}, + keywords="", + doi="10.17487/RFC3888", + } + +@misc{rfc3890, + author="M. Westerlund", + title="{A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)}", + howpublished="RFC 3890 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3890", + pages="1--22", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3890.txt", + key="RFC 3890", + abstract={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. 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]}, + keywords="tias, application specific maximum", + doi="10.17487/RFC3890", + } + +@misc{rfc3891, + author="R. Mahy and B. Biggs and R. Dean", + title="{The Session Initiation Protocol (SIP) ``Replaces'' Header}", + howpublished="RFC 3891 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3891", + pages="1--16", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3891.txt", + key="RFC 3891", + abstract={This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: ``Attended Transfer'' and ``Call Pickup''. Note that the definition of these example features is non-normative. [STANDARDS-TRACK]}, + keywords="multi-party applications, call control", + doi="10.17487/RFC3891", + } + +@misc{rfc3892, + author="R. Sparks", + title="{The Session Initiation Protocol (SIP) Referred-By Mechanism}", + howpublished="RFC 3892 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3892", + pages="1--25", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8217", +url="https://www.rfc-editor.org/rfc/rfc3892.txt", + key="RFC 3892", + abstract={The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK]}, + keywords="REFER", + doi="10.17487/RFC3892", + } + +@misc{rfc3893, + author="J. Peterson", + title="{Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format}", + howpublished="RFC 3893 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3893", + pages="1--13", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3893.txt", + key="RFC 3893", + abstract={RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. [STANDARDS-TRACK]}, + keywords="authenticated identity body, digitally-signed SIP message, message fragment, Authenticated Identity Bodies, AIB", + doi="10.17487/RFC3893", + } + +@misc{rfc3894, + author="J. Degener", + title="{Sieve Extension: Copying Without Side Effects}", + howpublished="RFC 3894 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3894", + pages="1--5", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3894.txt", + key="RFC 3894", + abstract={The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's ``inbox''. Actions such as ``fileinto'' and ``redirect'' cancel this default behavior. 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]}, + keywords="client, server", + doi="10.17487/RFC3894", + } + +@misc{rfc3895, + author="O. {Nicklass (Ed.)}", + title="{Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types}", + howpublished="RFC 3895 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3895", + pages="1--84", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4805", +url="https://www.rfc-editor.org/rfc/rfc3895.txt", + key="RFC 3895", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2495. [STANDARDS-TRACK]}, + keywords="management information base", + doi="10.17487/RFC3895", + } + +@misc{rfc3896, + author="O. {Nicklass (Ed.)}", + title="{Definitions of Managed Objects for the DS3/E3 Interface Type}", + howpublished="RFC 3896 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3896", + pages="1--63", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3896.txt", + key="RFC 3896", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2496. [STANDARDS-TRACK]}, + keywords="DS3-E3-MIB, management information base", + doi="10.17487/RFC3896", + } + +@misc{rfc3897, + author="A. Barbir", + title="{Open Pluggable Edge Services (OPES) Entities and End Points Communication}", + howpublished="RFC 3897 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3897", + pages="1--14", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3897.txt", + key="RFC 3897", + abstract={This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). This memo provides information for the Internet community.}, + keywords="tracing, non-blocking, bypass", + doi="10.17487/RFC3897", + } + +@misc{rfc3898, + author="V. Kalusivalingam", + title="{Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}", + howpublished="RFC 3898 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3898", + pages="1--7", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3898.txt", + key="RFC 3898", + abstract={This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. [STANDARDS-TRACK]}, + keywords="NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name", + doi="10.17487/RFC3898", + } + +@misc{rfc3901, + author="A. Durand and J. Ihren", + title="{DNS IPv6 Transport Operational Guidelines}", + howpublished="RFC 3901 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3901", + pages="1--5", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3901.txt", + key="RFC 3901", + abstract={This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="domain name system, internet protocol", + doi="10.17487/RFC3901", + } + +@misc{rfc3902, + author="M. Baker and M. Nottingham", + title="{The ``application/soap+xml'' media type}", + howpublished="RFC 3902 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3902", + pages="1--5", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3902.txt", + key="RFC 3902", + abstract={This document defines the ``application/soap+xml'' media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. This memo provides information for the Internet community.}, + doi="10.17487/RFC3902", + } + +@misc{rfc3903, + author="A. {Niemi (Ed.)}", + title="{Session Initiation Protocol (SIP) Extension for Event State Publication}", + howpublished="RFC 3903 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3903", + pages="1--32", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3903.txt", + key="RFC 3903", + abstract={This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. 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]}, + keywords="presence, information, package", + doi="10.17487/RFC3903", + } + +@misc{rfc3904, + author="C. Huitema and R. Austein and S. Satapati and R. van der Pol", + title="{Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks}", + howpublished="RFC 3904 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3904", + pages="1--19", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3904.txt", + key="RFC 3904", + abstract={This document analyzes issues involved in the transition of ``unmanaged networks'' from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. This memo provides information for the Internet community.}, + keywords="home office, internet protocol", + doi="10.17487/RFC3904", + } + +@misc{rfc3905, + author="V. {See (Ed.)}", + title="{A Template for IETF Patent Disclosures and Licensing Declarations}", + howpublished="RFC 3905 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3905", + pages="1--9", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3905.txt", + key="RFC 3905", + abstract={This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. This memo provides information for the Internet community.}, + keywords="ipr", + doi="10.17487/RFC3905", + } + +@misc{rfc3906, + author="N. Shen and H. Smit", + title="{Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels}", + howpublished="RFC 3906 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3906", + pages="1--8", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3906.txt", + key="RFC 3906", + abstract={This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. This memo provides information for the Internet community.}, + keywords="hop-by-hop link-state routing protocols, SPF, shortest path first", + doi="10.17487/RFC3906", + } + +@misc{rfc3909, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Cancel Operation}", + howpublished="RFC 3909 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3909", + pages="1--7", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3909.txt", + key="RFC 3909", + abstract={This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. [STANDARDS-TRACK]}, + keywords="abandon operation, outstanding operation", + doi="10.17487/RFC3909", + } + +@misc{rfc3910, + author="V. {Gurbani (Ed.)} and A. Brusilovsky and I. Faynberg and J. Gato and H. Lu and M. Unmehopa", + title="{The SPIRITS (Services in PSTN requesting Internet Services) Protocol}", + howpublished="RFC 3910 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3910", + pages="1--50", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3910.txt", + key="RFC 3910", + abstract={This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built. [STANDARDS-TRACK]}, + keywords="pstn, sip, services, event notification, eventpackages, internet call waiting, xml, wireless, intelligent network, in, detection point, dp", + doi="10.17487/RFC3910", + } + +@misc{rfc3911, + author="R. Mahy and D. Petrie", + title="{The Session Initiation Protocol (SIP) ``Join'' Header}", + howpublished="RFC 3911 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3911", + pages="1--17", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3911.txt", + key="RFC 3911", + abstract={This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: ``Barge-In'', answering-machine-style ``Message Screening'' and ``Call Center Monitoring''. Note that definition of these example features is non-normative. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3911", + } + +@misc{rfc3912, + author="L. Daigle", + title="{WHOIS Protocol Specification}", + howpublished="RFC 3912 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3912", + pages="1--4", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3912.txt", + key="RFC 3912", + abstract={This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]}, + keywords="NICNAME", + doi="10.17487/RFC3912", + } + +@misc{rfc3913, + author="D. Thaler", + title="{Border Gateway Multicast Protocol (BGMP): Protocol Specification}", + howpublished="RFC 3913 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="3913", + pages="1--41", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3913.txt", + key="RFC 3913", + abstract={This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports ``source-specific multicast'' (SSM). To also support ``any-source multicast'' (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domai n to be local to at least one of the session participants. This memo provides information for the Internet community.}, + keywords="enter-domain, source-specific multicast, ssm", + doi="10.17487/RFC3913", + } + +@misc{rfc3914, + author="A. Barbir and A. Rousskov", + title="{Open Pluggable Edge Services (OPES) Treatment of IAB Considerations}", + howpublished="RFC 3914 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3914", + pages="1--16", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3914.txt", + key="RFC 3914", + abstract={IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.}, + doi="10.17487/RFC3914", + } + +@misc{rfc3915, + author="S. Hollenbeck", + title="{Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 3915 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3915", + pages="1--23", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3915.txt", + key="RFC 3915", + abstract={This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to ``grace period'' policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]}, + keywords="dns, name system", + doi="10.17487/RFC3915", + } + +@misc{rfc3916, + author="X. {Xiao (Ed.)} and D. {McPherson (Ed.)} and P. {Pate (Ed.)}", + title="{Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)}", + howpublished="RFC 3916 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3916", + pages="1--19", + year=2004, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3916.txt", + key="RFC 3916", + abstract={This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., ``synchronous bit streams at rates defined by ITU G.702'') are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.}, + doi="10.17487/RFC3916", + } + +@misc{rfc3917, + author="J. Quittek and T. Zseby and B. Claise and S. Zander", + title="{Requirements for IP Flow Information Export (IPFIX)}", + howpublished="RFC 3917 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3917", + pages="1--33", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3917.txt", + key="RFC 3917", + abstract={This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.}, + keywords="ipfix, routers, measurment, middleboxes", + doi="10.17487/RFC3917", + } + +@misc{rfc3918, + author="D. Stopp and B. Hickman", + title="{Methodology for IP Multicast Benchmarking}", + howpublished="RFC 3918 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3918", + pages="1--31", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3918.txt", + key="RFC 3918", + abstract={The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. 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.}, + doi="10.17487/RFC3918", + } + +@misc{rfc3919, + author="E. Stephan and J. Palet", + title="{Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)}", + howpublished="RFC 3919 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3919", + pages="1--8", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3919.txt", + key="RFC 3919", + abstract={This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895]. 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.}, + keywords="mib", + doi="10.17487/RFC3919", + } + +@misc{rfc3920, + author="P. {Saint-Andre (Ed.)}", + title="{Extensible Messaging and Presence Protocol (XMPP): Core}", + howpublished="RFC 3920 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3920", + pages="1--30", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6120, updated by RFC 6122", +url="https://www.rfc-editor.org/rfc/rfc3920.txt", + key="RFC 3920", + abstract={This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]}, + keywords="instant messaging, im, extensible markup language, xml, jabber", + doi="10.17487/RFC3920", + } + +@misc{rfc3921, + author="P. {Saint-Andre (Ed.)}", + title="{Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence}", + howpublished="RFC 3921 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3921", + pages="1--107", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6121", +url="https://www.rfc-editor.org/rfc/rfc3921.txt", + key="RFC 3921", + abstract={This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]}, + keywords="instant messaging, im, extensible markup language, xml, jabber", + doi="10.17487/RFC3921", + } + +@misc{rfc3922, + author="P. Saint-Andre", + title="{Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)}", + howpublished="RFC 3922 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3922", + pages="1--34", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3922.txt", + key="RFC 3922", + abstract={This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]}, + keywords="xml, extensible markup language, im, instant messaging, jabber", + doi="10.17487/RFC3922", + } + +@misc{rfc3923, + author="P. Saint-Andre", + title="{End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 3923 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3923", + pages="1--27", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3923.txt", + key="RFC 3923", + abstract={This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]}, + keywords="xml, extensible markup language, im, instant messaging, jabber", + doi="10.17487/RFC3923", + } + +@misc{rfc3924, + author="F. Baker and B. Foster and C. Sharp", + title="{Cisco Architecture for Lawful Intercept in IP Networks}", + howpublished="RFC 3924 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3924", + pages="1--18", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3924.txt", + key="RFC 3924", + abstract={For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.}, + doi="10.17487/RFC3924", + } + +@misc{rfc3925, + author="J. Littlefield", + title="{Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)}", + howpublished="RFC 3925 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3925", + pages="1--9", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3925.txt", + key="RFC 3925", + abstract={The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]}, + keywords="dhc, dhcp, class, vendor-specific", + doi="10.17487/RFC3925", + } + +@misc{rfc3926, + author="T. Paila and M. Luby and R. Lehtonen and V. Roca and R. Walsh", + title="{FLUTE - File Delivery over Unidirectional Transport}", + howpublished="RFC 3926 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3926", + pages="1--35", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6726", +url="https://www.rfc-editor.org/rfc/rfc3926.txt", + key="RFC 3926", + abstract={This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC3926", + } + +@misc{rfc3927, + author="S. Cheshire and B. Aboba and E. Guttman", + title="{Dynamic Configuration of IPv4 Link-Local Addresses}", + howpublished="RFC 3927 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3927", + pages="1--33", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3927.txt", + key="RFC 3927", + abstract={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. 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 reco mmend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK]}, + keywords="ip network, ip address, 169.254/16", + doi="10.17487/RFC3927", + } + +@misc{rfc3928, + author="R. {Megginson (Ed.)} and M. Smith and O. Natkovich and J. Parham", + title="{Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)}", + howpublished="RFC 3928 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3928", + pages="1--30", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3928.txt", + key="RFC 3928", + abstract={This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3928", + } + +@misc{rfc3929, + author="T. Hardie", + title="{Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF}", + howpublished="RFC 3929 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3929", + pages="1--11", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3929.txt", + key="RFC 3929", + abstract={This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC3929", + } + +@misc{rfc3930, + author="D. {Eastlake 3rd}", + title="{The Protocol versus Document Points of View in Computer Protocols}", + howpublished="RFC 3930 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3930", + pages="1--15", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3930.txt", + key="RFC 3930", + abstract={This document contrasts two points of view: the ``document'' point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the ``protocol'' point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.}, + doi="10.17487/RFC3930", + } + +@misc{rfc3931, + author="J. {Lau (Ed.)} and M. {Townsley (Ed.)} and I. {Goyret (Ed.)}", + title="{Layer Two Tunneling Protocol - Version 3 (L2TPv3)}", + howpublished="RFC 3931 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3931", + pages="1--94", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5641", +url="https://www.rfc-editor.org/rfc/rfc3931.txt", + key="RFC 3931", + abstract={This document describes ``version 3'' of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]}, + keywords="L2TP, ppp, point-to-point, protocol, packets", + doi="10.17487/RFC3931", + } + +@misc{rfc3932, + author="H. Alvestrand", + title="{The IESG and RFC Editor Documents: Procedures}", + howpublished="RFC 3932 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3932", + pages="1--8", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5742", +url="https://www.rfc-editor.org/rfc/rfc3932.txt", + key="RFC 3932", + abstract={This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004. 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.}, + keywords="independent submission", + doi="10.17487/RFC3932", + } + +@misc{rfc3933, + author="J. Klensin and S. Dawkins", + title="{A Model for IETF Process Experiments}", + howpublished="RFC 3933 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3933", + pages="1--7", + year=2004, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3933.txt", + key="RFC 3933", + abstract={The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. 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.}, + keywords="", + doi="10.17487/RFC3933", + } + +@misc{rfc3934, + author="M. Wasserman", + title="{Updates to RFC 2418 Regarding the Management of IETF Mailing Lists}", + howpublished="RFC 3934 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3934", + pages="1--5", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3934.txt", + key="RFC 3934", + abstract={This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="BCP, WG, escape, clause, procedures", + doi="10.17487/RFC3934", + } + +@misc{rfc3935, + author="H. Alvestrand", + title="{A Mission Statement for the IETF}", + howpublished="RFC 3935 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3935", + pages="1--7", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3935.txt", + key="RFC 3935", + abstract={This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC3935", + } + +@misc{rfc3936, + author="K. Kompella and J. Lang", + title="{Procedures for Modifying the Resource reSerVation Protocol (RSVP)}", + howpublished="RFC 3936 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3936", + pages="1--7", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3936.txt", + key="RFC 3936", + abstract={This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="resource, reservation, protocol, label, switched, paths", + doi="10.17487/RFC3936", + } + +@misc{rfc3937, + author="M. Steidl", + title="{A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)}", + howpublished="RFC 3937 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3937", + pages="1--9", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3937.txt", + key="RFC 3937", + abstract={This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.}, + doi="10.17487/RFC3937", + } + +@misc{rfc3938, + author="T. Hansen", + title="{Video-Message Message-Context}", + howpublished="RFC 3938 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3938", + pages="1--4", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3938.txt", + key="RFC 3938", + abstract={The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: ``video-message''. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]}, + keywords="user agent, ua", + doi="10.17487/RFC3938", + } + +@misc{rfc3939, + author="G. Parsons and J. Maruszak", + title="{Calling Line Identification for Voice Mail Messages}", + howpublished="RFC 3939 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3939", + pages="1--11", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3939.txt", + key="RFC 3939", + abstract={This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller\_ID and Called\_Name. Caller\_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3939", + } + +@misc{rfc3940, + author="B. Adamson and C. Bormann and M. Handley and J. Macker", + title="{Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol}", + howpublished="RFC 3940 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3940", + pages="1--80", + year=2004, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5740", +url="https://www.rfc-editor.org/rfc/rfc3940.txt", + key="RFC 3940", + abstract={This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal ``a priori'' coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or pos sibly 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.}, + keywords="", + doi="10.17487/RFC3940", + } + +@misc{rfc3941, + author="B. Adamson and C. Bormann and M. Handley and J. Macker", + title="{Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks}", + howpublished="RFC 3941 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3941", + pages="1--36", + year=2004, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5401", +url="https://www.rfc-editor.org/rfc/rfc3941.txt", + key="RFC 3941", + abstract={This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional ``building blocks'' that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC3941", + } + +@misc{rfc3942, + author="B. Volz", + title="{Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options}", + howpublished="RFC 3942 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3942", + pages="1--7", + year=2004, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3942.txt", + key="RFC 3942", + abstract={This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]}, + keywords="DHCP-BOOTP, Bootstrap", + doi="10.17487/RFC3942", + } + +@misc{rfc3943, + author="R. Friend", + title="{Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)}", + howpublished="RFC 3943 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3943", + pages="1--13", + year=2004, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3943.txt", + key="RFC 3943", + abstract={The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.}, + keywords="lossless data compression algorithm, TLS Record Protocol", + doi="10.17487/RFC3943", + } + +@misc{rfc3944, + author="T. Johnson and S. Okubo and S. Campos", + title="{H.350 Directory Services}", + howpublished="RFC 3944 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3944", + pages="1--30", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3944.txt", + key="RFC 3944", + abstract={The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. 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.}, + keywords="ldap, directory services, h.350, h.323, h.320, h.235, sip", + doi="10.17487/RFC3944", + } + +@misc{rfc3945, + author="E. {Mannie (Ed.)}", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Architecture}", + howpublished="RFC 3945 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3945", + pages="1--69", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6002", +url="https://www.rfc-editor.org/rfc/rfc3945.txt", + key="RFC 3945", + abstract={Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. 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]}, + keywords="", + doi="10.17487/RFC3945", + } + +@misc{rfc3946, + author="E. Mannie and D. Papadimitriou", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control}", + howpublished="RFC 3946 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3946", + pages="1--26", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4606", +url="https://www.rfc-editor.org/rfc/rfc3946.txt", + key="RFC 3946", + abstract={This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]}, + doi="10.17487/RFC3946", + } + +@misc{rfc3947, + author="T. Kivinen and B. Swander and A. Huttunen and V. Volpe", + title="{Negotiation of NAT-Traversal in the IKE}", + howpublished="RFC 3947 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3947", + pages="1--16", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3947.txt", + key="RFC 3947", + abstract={This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3947", + } + +@misc{rfc3948, + author="A. Huttunen and B. Swander and V. Volpe and L. DiBurro and M. Stenberg", + title="{UDP Encapsulation of IPsec ESP Packets}", + howpublished="RFC 3948 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3948", + pages="1--15", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3948.txt", + key="RFC 3948", + abstract={This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3948", + } + +@misc{rfc3949, + author="R. Buckley and D. Venable and L. McIntyre and G. Parsons and J. Rafferty", + title="{File Format for Internet Fax}", + howpublished="RFC 3949 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3949", + pages="1--84", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3949.txt", + key="RFC 3949", + abstract={This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing. 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]}, + keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions", + doi="10.17487/RFC3949", + } + +@misc{rfc3950, + author="L. McIntyre and G. Parsons and J. Rafferty", + title="{Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration}", + howpublished="RFC 3950 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3950", + pages="1--8", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3950.txt", + key="RFC 3950", + abstract={This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]}, + keywords="FFIF, TIFF, Tag, Image, facsimile, MIME, multipurpose, Internet, mail, extensions", + doi="10.17487/RFC3950", + } + +@misc{rfc3951, + author="S. Andersen and A. Duric and H. Astrom and R. Hagen and W. Kleijn and J. Linden", + title="{Internet Low Bit Rate Codec (iLBC)}", + howpublished="RFC 3951 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3951", + pages="1--194", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3951.txt", + key="RFC 3951", + abstract={This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC3951", + } + +@misc{rfc3952, + author="A. Duric and S. Andersen", + title="{Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech}", + howpublished="RFC 3952 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3952", + pages="1--13", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3952.txt", + key="RFC 3952", + abstract={This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC3952", + } + +@misc{rfc3953, + author="J. Peterson", + title="{Telephone Number Mapping (ENUM) Service Registration for Presence Services}", + howpublished="RFC 3953 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3953", + pages="1--7", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc3953.txt", + key="RFC 3953", + abstract={This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]}, + keywords="uniform resource identifier, uri, provisioning pres", + doi="10.17487/RFC3953", + } + +@misc{rfc3954, + author="B. {Claise (Ed.)}", + title="{Cisco Systems NetFlow Services Export Version 9}", + howpublished="RFC 3954 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3954", + pages="1--33", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3954.txt", + key="RFC 3954", + abstract={This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.}, + doi="10.17487/RFC3954", + } + +@misc{rfc3955, + author="S. Leinen", + title="{Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)}", + howpublished="RFC 3955 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3955", + pages="1--23", + year=2004, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3955.txt", + key="RFC 3955", + abstract={This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.}, + doi="10.17487/RFC3955", + } + +@misc{rfc3956, + author="P. Savola and B. Haberman", + title="{Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address}", + howpublished="RFC 3956 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3956", + pages="1--18", + year=2004, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7371", +url="https://www.rfc-editor.org/rfc/rfc3956.txt", + key="RFC 3956", + abstract={This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]}, + keywords="internet protocol", + doi="10.17487/RFC3956", + } + +@misc{rfc3957, + author="C. Perkins and P. Calhoun", + title="{Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4}", + howpublished="RFC 3957 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3957", + pages="1--27", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3957.txt", + key="RFC 3957", + abstract={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]}, + keywords="", + doi="10.17487/RFC3957", + } + +@misc{rfc3958, + author="L. Daigle and A. Newton", + title="{Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)}", + howpublished="RFC 3958 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3958", + pages="1--25", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3958.txt", + key="RFC 3958", + abstract={This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3958", + } + +@misc{rfc3959, + author="G. Camarillo", + title="{The Early Session Disposition Type for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3959 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3959", + pages="1--11", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3959.txt", + key="RFC 3959", + abstract={This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of ``early-session'' bodies is similar to the treatment of ``session'' bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is ``early-session'' are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3959", + } + +@misc{rfc3960, + author="G. Camarillo and H. Schulzrinne", + title="{Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)}", + howpublished="RFC 3960 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3960", + pages="1--13", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3960.txt", + key="RFC 3960", + abstract={This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.}, + doi="10.17487/RFC3960", + } + +@misc{rfc3961, + author="K. Raeburn", + title="{Encryption and Checksum Specifications for Kerberos 5}", + howpublished="RFC 3961 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3961", + pages="1--50", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3961.txt", + key="RFC 3961", + abstract={This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered ``required to implement''. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3961", + } + +@misc{rfc3962, + author="K. Raeburn", + title="{Advanced Encryption Standard (AES) Encryption for Kerberos 5}", + howpublished="RFC 3962 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3962", + pages="1--16", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3962.txt", + key="RFC 3962", + abstract={The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]}, + keywords="kerberos cryptosystem suite", + doi="10.17487/RFC3962", + } + +@misc{rfc3963, + author="V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert", + title="{Network Mobility (NEMO) Basic Support Protocol}", + howpublished="RFC 3963 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3963", + pages="1--33", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3963.txt", + key="RFC 3963", + abstract={This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]}, + keywords="mobile ipv6, session continuity", + doi="10.17487/RFC3963", + } + +@misc{rfc3964, + author="P. Savola and C. Patel", + title="{Security Considerations for 6to4}", + howpublished="RFC 3964 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3964", + pages="1--41", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3964.txt", + key="RFC 3964", + abstract={The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 (``IPv6-in-IPv4'') traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community.}, + doi="10.17487/RFC3964", + } + +@misc{rfc3965, + author="K. Toyoda and H. Ohno and J. Murai and D. Wing", + title="{A Simple Mode of Facsimile Using Internet Mail}", + howpublished="RFC 3965 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="3965", + pages="1--14", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3965.txt", + key="RFC 3965", + abstract={This specification provides for ``simple mode'' carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. This document is a revision of RFC 2305. There have been no technical changes. [STANDARDS-TRACK]}, + keywords="SMFAX-IM, data, file, format, e-mail", + doi="10.17487/RFC3965", + } + +@misc{rfc3966, + author="H. Schulzrinne", + title="{The tel URI for Telephone Numbers}", + howpublished="RFC 3966 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3966", + pages="1--17", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5341", +url="https://www.rfc-editor.org/rfc/rfc3966.txt", + key="RFC 3966", + abstract={This document specifies the URI (Uniform Resource Identifier) scheme ``tel''. The ``tel'' URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK]}, + keywords="uniform, resource, locator, schemes", + doi="10.17487/RFC3966", + } + +@misc{rfc3967, + author="R. Bush and T. Narten", + title="{Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level}", + howpublished="RFC 3967 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3967", + pages="1--6", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4897, 8067", +url="https://www.rfc-editor.org/rfc/rfc3967.txt", + key="RFC 3967", + abstract={IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + doi="10.17487/RFC3967", + } + +@misc{rfc3968, + author="G. Camarillo", + title="{The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3968 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3968", + pages="1--8", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3968.txt", + key="RFC 3968", + abstract={This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC3968", + } + +@misc{rfc3969, + author="G. Camarillo", + title="{The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)}", + howpublished="RFC 3969 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3969", + pages="1--6", + year=2004, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5727", +url="https://www.rfc-editor.org/rfc/rfc3969.txt", + key="RFC 3969", + abstract={This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC3969", + } + +@misc{rfc3970, + author="K. Kompella", + title="{A Traffic Engineering (TE) MIB}", + howpublished="RFC 3970 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3970", + pages="1--44", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3970.txt", + key="RFC 3970", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3970", + } + +@misc{rfc3971, + author="J. {Arkko (Ed.)} and J. Kempf and B. Zill and P. Nikander", + title="{SEcure Neighbor Discovery (SEND)}", + howpublished="RFC 3971 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3971", + pages="1--56", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6494, 6495, 6980", +url="https://www.rfc-editor.org/rfc/rfc3971.txt", + key="RFC 3971", + abstract={IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]}, + keywords="Neighbor Discovery Protocol, NDP", + doi="10.17487/RFC3971", + } + +@misc{rfc3972, + author="T. Aura", + title="{Cryptographically Generated Addresses (CGA)}", + howpublished="RFC 3972 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3972", + pages="1--22", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4581, 4982", +url="https://www.rfc-editor.org/rfc/rfc3972.txt", + key="RFC 3972", + abstract={This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK]}, + keywords="Secure Neighbor Discovery, SEND", + doi="10.17487/RFC3972", + } + +@misc{rfc3973, + author="A. Adams and J. Nicholas and W. Siadak", + title="{Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)}", + howpublished="RFC 3973 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3973", + pages="1--61", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3973.txt", + key="RFC 3973", + abstract={This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.}, + keywords="multicast routing protocol, prune messages", + doi="10.17487/RFC3973", + } + +@misc{rfc3974, + author="M. Nakamura and J. Hagino", + title="{SMTP Operational Experience in Mixed IPv4/v6 Environments}", + howpublished="RFC 3974 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3974", + pages="1--10", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3974.txt", + key="RFC 3974", + abstract={This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. This document does not define any new protocol. This memo provides information for the Internet community.}, + keywords="simple mail transfer protocol, dual stack, dualstack, ipv4, ipv6", + doi="10.17487/RFC3974", + } + +@misc{rfc3975, + author="G. {Huston (Ed.)} and I. {Leuca (Ed.)}", + title="{OMA-IETF Standardization Collaboration}", + howpublished="RFC 3975 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3975", + pages="1--9", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3975.txt", + key="RFC 3975", + abstract={This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.}, + keywords="oopen mobile alliance, ietf, internet engineering task force", + doi="10.17487/RFC3975", + } + +@misc{rfc3976, + author="V. K. Gurbani and F. Haerens and V. Rastogi", + title="{Interworking SIP and Intelligent Network (IN) Applications}", + howpublished="RFC 3976 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3976", + pages="1--25", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3976.txt", + key="RFC 3976", + abstract={Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). This memo provides information for the Internet community.}, + keywords="sip, intelligent network, call models, call model mapping, telephony services, public switched telephone network, pstn", + doi="10.17487/RFC3976", + } + +@misc{rfc3977, + author="C. Feather", + title="{Network News Transfer Protocol (NNTP)}", + howpublished="RFC 3977 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3977", + pages="1--125", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6048", +url="https://www.rfc-editor.org/rfc/rfc3977.txt", + key="RFC 3977", + abstract={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]}, + keywords="usenet, netnews", + doi="10.17487/RFC3977", + } + +@misc{rfc3978, + author="S. {Bradner (Ed.)}", + title="{IETF Rights in Contributions}", + howpublished="RFC 3978 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3978", + pages="1--18", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5378, updated by RFC 4748", +url="https://www.rfc-editor.org/rfc/rfc3978.txt", + key="RFC 3978", + abstract={The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="intellectual property rights, copyright, ipr", + doi="10.17487/RFC3978", + } + +@misc{rfc3979, + author="S. {Bradner (Ed.)}", + title="{Intellectual Property Rights in IETF Technology}", + howpublished="RFC 3979 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="3979", + pages="1--17", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8179, updated by RFC 4879", +url="https://www.rfc-editor.org/rfc/rfc3979.txt", + key="RFC 3979", + abstract={The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="ipr, copyright", + doi="10.17487/RFC3979", + } + +@misc{rfc3980, + author="M. Krueger and M. Chadalapaka and R. Elliott", + title="{T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names}", + howpublished="RFC 3980 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3980", + pages="1--8", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7143", +url="https://www.rfc-editor.org/rfc/rfc3980.txt", + key="RFC 3980", + abstract={Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the ``Network Address Authority'' (NAA) worldwide naming format defined by the InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This document updates RFC 3720. [STANDARDS-TRACK]}, + keywords="internet small computer systems interface, scsi transport protocol", + doi="10.17487/RFC3980", + } + +@misc{rfc3981, + author="A. Newton and M. Sanz", + title="{IRIS: The Internet Registry Information Service (IRIS) Core Protocol}", + howpublished="RFC 3981 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3981", + pages="1--52", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4992", +url="https://www.rfc-editor.org/rfc/rfc3981.txt", + key="RFC 3981", + abstract={This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3981", + } + +@misc{rfc3982, + author="A. Newton and M. Sanz", + title="{IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)}", + howpublished="RFC 3982 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3982", + pages="1--50", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3982.txt", + key="RFC 3982", + abstract={This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3982", + } + +@misc{rfc3983, + author="A. Newton and M. Sanz", + title="{Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)}", + howpublished="RFC 3983 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3983", + pages="1--12", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3983.txt", + key="RFC 3983", + abstract={This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3983", + } + +@misc{rfc3984, + author="S. Wenger and M.M. Hannuksela and T. Stockhammer and M. Westerlund and D. Singer", + title="{RTP Payload Format for H.264 Video}", + howpublished="RFC 3984 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3984", + pages="1--83", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6184", +url="https://www.rfc-editor.org/rfc/rfc3984.txt", + key="RFC 3984", + abstract={This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. [STANDARDS-TRACK]}, + keywords="ITU-T Recommendation H.264, ISO/IEC International Standard 14496-10", + doi="10.17487/RFC3984", + } + +@misc{rfc3985, + author="S. {Bryant (Ed.)} and P. {Pate (Ed.)}", + title="{Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture}", + howpublished="RFC 3985 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3985", + pages="1--42", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc3985.txt", + key="RFC 3985", + abstract={This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.}, + doi="10.17487/RFC3985", + } + +@misc{rfc3986, + author="T. Berners-Lee and R. Fielding and L. Masinter", + title="{Uniform Resource Identifier (URI): Generic Syntax}", + howpublished="RFC 3986 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="3986", + pages="1--61", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6874, 7320", +url="https://www.rfc-editor.org/rfc/rfc3986.txt", + key="RFC 3986", + abstract={A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]}, + keywords="Internet, protocol, uniform, resource, identifier, www, world wide web", + doi="10.17487/RFC3986", + } + +@misc{rfc3987, + author="M. Duerst and M. Suignard", + title="{Internationalized Resource Identifiers (IRIs)}", + howpublished="RFC 3987 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3987", + pages="1--46", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3987.txt", + key="RFC 3987", + abstract={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. 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.}, + keywords="uri, uniform resource identifier, Universal Character Set", + doi="10.17487/RFC3987", + } + +@misc{rfc3988, + author="B. Black and K. Kompella", + title="{Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol}", + howpublished="RFC 3988 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="3988", + pages="1--9", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3988.txt", + key="RFC 3988", + abstract={Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms. This document specifies experimental extensions to LDP in support of LSP MTU discovery. This memo defines an Experimental Protocol for the Internet community.}, + keywords="mtu, ldp, lsp, label switched path, label switching router, lsr", + doi="10.17487/RFC3988", + } + +@misc{rfc3989, + author="M. Stiemerling and J. Quittek and T. Taylor", + title="{Middlebox Communications (MIDCOM) Protocol Semantics}", + howpublished="RFC 3989 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3989", + pages="1--70", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5189", +url="https://www.rfc-editor.org/rfc/rfc3989.txt", + key="RFC 3989", + abstract={This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This memo provides information for the Internet community.}, + keywords="nat, network address translator, firewall", + doi="10.17487/RFC3989", + } + +@misc{rfc3990, + author="B. O'Hara and P. Calhoun and J. Kempf", + title="{Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement}", + howpublished="RFC 3990 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3990", + pages="1--5", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3990.txt", + key="RFC 3990", + abstract={This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. This memo provides information for the Internet community.}, + doi="10.17487/RFC3990", + } + +@misc{rfc3991, + author="B. Foster and F. Andreasen", + title="{Media Gateway Control Protocol (MGCP) Redirect and Reset Package}", + howpublished="RFC 3991 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3991", + pages="1--11", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3991.txt", + key="RFC 3991", + abstract={The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. This memo provides information for the Internet community.}, + keywords="voice, IP, internet, VoIP", + doi="10.17487/RFC3991", + } + +@misc{rfc3992, + author="B. Foster and F. Andreasen", + title="{Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism}", + howpublished="RFC 3992 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3992", + pages="1--5", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3992.txt", + key="RFC 3992", + abstract={A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. This memo provides information for the Internet community.}, + keywords="fault recovery", + doi="10.17487/RFC3992", + } + +@misc{rfc3993, + author="R. Johnson and T. Palaniappan and M. Stapp", + title="{Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option}", + howpublished="RFC 3993 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3993", + pages="1--7", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3993.txt", + key="RFC 3993", + abstract={This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable ``Subscriber-ID'' with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC3993", + } + +@misc{rfc3994, + author="H. Schulzrinne", + title="{Indication of Message Composition for Instant Messaging}", + howpublished="RFC 3994 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3994", + pages="1--13", + year=2005, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3994.txt", + key="RFC 3994", + abstract={In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS-TRACK]}, + keywords="im, status message content type, xml, extensible markup language", + doi="10.17487/RFC3994", + } + +@misc{rfc3995, + author="R. Herriot and T. Hastings", + title="{Internet Printing Protocol (IPP): Event Notifications and Subscriptions}", + howpublished="RFC 3995 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3995", + pages="1--95", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3995.txt", + key="RFC 3995", + abstract={This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). 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]}, + keywords="optional, subscription events, subscription objects, asynchronous even notification", + doi="10.17487/RFC3995", + } + +@misc{rfc3996, + author="R. Herriot and T. Hastings and H. Lewis", + title="{Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications}", + howpublished="RFC 3996 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3996", + pages="1--31", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3996.txt", + key="RFC 3996", + abstract={This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the ``Internet Printing Protocol (IPP): Event Notifications and Subscriptions'' specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. [STANDARDS-TRACK]}, + keywords="pull delivery method, event notifications, event subscriptions", + doi="10.17487/RFC3996", + } + +@misc{rfc3997, + author="T. {Hastings (Ed.)} and R. K. deBry and H. Lewis", + title="{Internet Printing Protocol (IPP): Requirements for IPP Notifications}", + howpublished="RFC 3997 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="3997", + pages="1--17", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3997.txt", + key="RFC 3997", + abstract={This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. This memo provides information for the Internet community.}, + keywords="model, directory services, notification requirements", + doi="10.17487/RFC3997", + } + +@misc{rfc3998, + author="C. Kugler and H. Lewis and T. {Hastings (Ed.)}", + title="{Internet Printing Protocol (IPP): Job and Printer Administrative Operations}", + howpublished="RFC 3998 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="3998", + pages="1--46", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc3998.txt", + key="RFC 3998", + abstract={This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet Printing Protocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. (Printer operations: Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer. Job operations: Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After.) [STANDARDS-TRACK]}, + keywords="system administration 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, Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After", + doi="10.17487/RFC3998", + } + +@misc{rfc4001, + author="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder", + title="{Textual Conventions for Internet Network Addresses}", + howpublished="RFC 4001 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4001", + pages="1--22", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4001.txt", + key="RFC 4001", + abstract={This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]}, + keywords="MIB, management information base, internet network layer addressing information", + doi="10.17487/RFC4001", + } + +@misc{rfc4002, + author="R. Brandner and L. Conroy and R. Stastny", + title="{IANA Registration for Enumservice 'web' and 'ft'}", + howpublished="RFC 4002 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4002", + pages="1--10", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4002.txt", + key="RFC 4002", + abstract={This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). [STANDARDS-TRACK]}, + keywords="URI schemes, uniform resource identifier, enum", + doi="10.17487/RFC4002", + } + +@misc{rfc4003, + author="L. Berger", + title="{GMPLS Signaling Procedure for Egress Control}", + howpublished="RFC 4003 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4003", + pages="1--5", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4003.txt", + key="RFC 4003", + abstract={This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as ``Egress Control''. Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. [STANDARDS-TRACK]}, + keywords="lsp, label switch path, gmpls signaling", + doi="10.17487/RFC4003", + } + +@misc{rfc4004, + author="P. Calhoun and T. Johansson and C. Perkins and T. {Hiller (Ed.)} and P. McCann", + title="{Diameter Mobile IPv4 Application}", + howpublished="RFC 4004 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4004", + pages="1--53", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4004.txt", + key="RFC 4004", + abstract={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]}, + keywords="internet protocol version 4, aaa, authentication, authorization, accounting, inter-realm, diameter accounting", + doi="10.17487/RFC4004", + } + +@misc{rfc4005, + author="P. Calhoun and G. Zorn and D. Spence and D. Mitton", + title="{Diameter Network Access Server Application}", + howpublished="RFC 4005 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4005", + pages="1--85", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7155", +url="https://www.rfc-editor.org/rfc/rfc4005.txt", + key="RFC 4005", + abstract={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. 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. 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]}, + keywords="aaa, authentication, authorization, accounting, nas, diameter base, transport profile, extensible authentication protocol, radius", + doi="10.17487/RFC4005", + } + +@misc{rfc4006, + author="H. Hakala and L. Mattila and J-P. Koskinen and M. Stura and J. Loughney", + title="{Diameter Credit-Control Application}", + howpublished="RFC 4006 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4006", + pages="1--114", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4006.txt", + key="RFC 4006", + abstract={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]}, + keywords="real-time credit-control", + doi="10.17487/RFC4006", + } + +@misc{rfc4007, + author="S. Deering and B. Haberman and T. Jinmei and E. Nordmark and B. Zill", + title="{IPv6 Scoped Address Architecture}", + howpublished="RFC 4007 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4007", + pages="1--24", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7346", +url="https://www.rfc-editor.org/rfc/rfc4007.txt", + key="RFC 4007", + abstract={This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]}, + keywords="architectural characteristics, expected behavior, textual representation", + doi="10.17487/RFC4007", + } + +@misc{rfc4008, + author="R. Rohit and P. Srisuresh and R. Raghunarayan and N. Pai and C. Wang", + title="{Definitions of Managed Objects for Network Address Translators (NAT)}", + howpublished="RFC 4008 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4008", + pages="1--64", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7658", +url="https://www.rfc-editor.org/rfc/rfc4008.txt", + key="RFC 4008", + abstract={This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS-TRACK]}, + keywords="mib, management information base", + doi="10.17487/RFC4008", + } + +@misc{rfc4009, + author="J. Park and S. Lee and J. Kim and J. Lee", + title="{The SEED Encryption Algorithm}", + howpublished="RFC 4009 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4009", + pages="1--17", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4269", +url="https://www.rfc-editor.org/rfc/rfc4009.txt", + key="RFC 4009", + abstract={This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This memo provides information for the Internet community.}, + keywords="encryption algorithm, seed cbc, seed oid", + doi="10.17487/RFC4009", + } + +@misc{rfc4010, + author="J. Park and S. Lee and J. Kim and J. Lee", + title="{Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 4010 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4010", + pages="1--13", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4010.txt", + key="RFC 4010", + abstract={This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). 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]}, + keywords="smime, secure/multipurpose internet mail extensions", + doi="10.17487/RFC4010", + } + +@misc{rfc4011, + author="S. Waldbusser and J. Saperia and T. Hongal", + title="{Policy Based Management MIB}", + howpublished="RFC 4011 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4011", + pages="1--121", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4011.txt", + key="RFC 4011", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. [STANDARDS-TRACK]}, + keywords="management information base, Simple Network Management Protocol, snmp, infrastructures, scripting language, script execution environment", + doi="10.17487/RFC4011", + } + +@misc{rfc4012, + author="L. Blunk and J. Damas and F. Parent and A. Robachevsky", + title="{Routing Policy Specification Language next generation (RPSLng)}", + howpublished="RFC 4012 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4012", + pages="1--16", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7909", +url="https://www.rfc-editor.org/rfc/rfc4012.txt", + key="RFC 4012", + abstract={This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4012", + } + +@misc{rfc4013, + author="K. Zeilenga", + title="{SASLprep: Stringprep Profile for User Names and Passwords}", + howpublished="RFC 4013 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4013", + pages="1--6", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7613", +url="https://www.rfc-editor.org/rfc/rfc4013.txt", + key="RFC 4013", + abstract={This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the ``SASLprep'' profile of the ``stringprep'' algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS-TRACK]}, + keywords="unicode strings, saslprep, stringprep, sasl, simple authentication and security layer", + doi="10.17487/RFC4013", + } + +@misc{rfc4014, + author="R. Droms and J. Schnizlein", + title="{Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option}", + howpublished="RFC 4014 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4014", + pages="1--8", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4014.txt", + key="RFC 4014", + abstract={The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4014", + } + +@misc{rfc4015, + author="R. Ludwig and A. Gurtov", + title="{The Eifel Response Algorithm for TCP}", + howpublished="RFC 4015 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4015", + pages="1--13", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4015.txt", + key="RFC 4015", + abstract={Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. [STANDARDS-TRACK]}, + keywords="transmision control protocol", + doi="10.17487/RFC4015", + } + +@misc{rfc4016, + author="M. Parthasarathy", + title="{Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements}", + howpublished="RFC 4016 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4016", + pages="1--15", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4016.txt", + key="RFC 4016", + abstract={This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. This memo provides information for the Internet community.}, + keywords="authentication, network access", + doi="10.17487/RFC4016", + } + +@misc{rfc4017, + author="D. Stanley and J. Walker and B. Aboba", + title="{Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs}", + howpublished="RFC 4017 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4017", + pages="1--11", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4017.txt", + key="RFC 4017", + abstract={The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.}, + keywords="IEEE 802.11, wireless lan", + doi="10.17487/RFC4017", + } + +@misc{rfc4018, + author="M. Bakke and J. Hufferd and K. Voruganti and M. Krueger and T. Sperry", + title="{Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)}", + howpublished="RFC 4018 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4018", + pages="1--23", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc4018.txt", + key="RFC 4018", + abstract={The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. [PROPOSED STANDARD]}, + keywords="scsi, slp", + doi="10.17487/RFC4018", + } + +@misc{rfc4019, + author="G. Pelletier", + title="{RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite}", + howpublished="RFC 4019 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4019", + pages="1--23", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4815", +url="https://www.rfc-editor.org/rfc/rfc4019.txt", + key="RFC 4019", + abstract={This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS-TRACK]}, + keywords="rtp, udp-lite, ip, real-time transport protocol, user datagram protocol lite, internet protocol", + doi="10.17487/RFC4019", + } + +@misc{rfc4020, + author="K. Kompella and A. Zinin", + title="{Early IANA Allocation of Standards Track Code Points}", + howpublished="RFC 4020 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4020", + pages="1--7", + year=2005, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7120", +url="https://www.rfc-editor.org/rfc/rfc4020.txt", + key="RFC 4020", + abstract={This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the ``Standards Action'' IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC4020", + } + +@misc{rfc4021, + author="G. Klyne and J. Palme", + title="{Registration of Mail and MIME Header Fields}", + howpublished="RFC 4021 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4021", + pages="1--54", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5322", +url="https://www.rfc-editor.org/rfc/rfc4021.txt", + key="RFC 4021", + abstract={This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]}, + keywords="IANA", + doi="10.17487/RFC4021", + } + +@misc{rfc4022, + author="R. {Raghunarayan (Ed.)}", + title="{Management Information Base for the Transmission Control Protocol (TCP)}", + howpublished="RFC 4022 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4022", + pages="1--24", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4022.txt", + key="RFC 4022", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. [STANDARDS-TRACK]}, + keywords="MIB-TCP, TCP, Simple Network Management Protocol, MIB", + doi="10.17487/RFC4022", + } + +@misc{rfc4023, + author="T. Worster and Y. Rekhter and E. {Rosen (Ed.)}", + title="{Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)}", + howpublished="RFC 4023 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4023", + pages="1--14", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5332", +url="https://www.rfc-editor.org/rfc/rfc4023.txt", + key="RFC 4023", + abstract={Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4023", + } + +@misc{rfc4024, + author="G. Parsons and J. Maruszak", + title="{Voice Messaging Client Behaviour}", + howpublished="RFC 4024 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4024", + pages="1--9", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4024.txt", + key="RFC 4024", + abstract={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.}, + keywords="vpim, profile, internet mail, voice profile for internet mail, fax message", + doi="10.17487/RFC4024", + } + +@misc{rfc4025, + author="M. Richardson", + title="{A Method for Storing IPsec Keying Material in DNS}", + howpublished="RFC 4025 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4025", + pages="1--12", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4025.txt", + key="RFC 4025", + abstract={This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question. This record replaces the functionality of the sub-type \#4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4025", + } + +@misc{rfc4026, + author="L. Andersson and T. Madsen", + title="{Provider Provisioned Virtual Private Network (VPN) Terminology}", + howpublished="RFC 4026 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4026", + pages="1--20", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4026.txt", + key="RFC 4026", + abstract={The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. 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.}, + keywords="l3vpn, l2vpn", + doi="10.17487/RFC4026", + } + +@misc{rfc4027, + author="S. Josefsson", + title="{Domain Name System Media Types}", + howpublished="RFC 4027 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4027", + pages="1--6", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4027.txt", + key="RFC 4027", + abstract={This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. This memo provides information for the Internet community.}, + keywords="media type, application/dns, text/dns", + doi="10.17487/RFC4027", + } + +@misc{rfc4028, + author="S. Donovan and J. Rosenberg", + title="{Session Timers in the Session Initiation Protocol (SIP)}", + howpublished="RFC 4028 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4028", + pages="1--27", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4028.txt", + key="RFC 4028", + abstract={This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a \\\%re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: \\\%Session-Expires, which conveys the lifetime of the session, and \\\%Min-SE, which conveys the minimum allowed value for the session timer. [STANDARDS-TRACK]}, + keywords="re-invite request, update request, session-expires, min-se", + doi="10.17487/RFC4028", + } + +@misc{rfc4029, + author="M. Lind and V. Ksinant and S. Park and A. Baudot and P. Savola", + title="{Scenarios and Analysis for Introducing IPv6 into ISP Networks}", + howpublished="RFC 4029 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4029", + pages="1--28", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4029.txt", + key="RFC 4029", + abstract={This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified. This memo provides information for the Internet community.}, + keywords="internet service provider, internet protocol", + doi="10.17487/RFC4029", + } + +@misc{rfc4030, + author="M. Stapp and T. Lemon", + title="{The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option}", + howpublished="RFC 4030 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4030", + pages="1--15", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4030.txt", + key="RFC 4030", + abstract={The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4030", + } + +@misc{rfc4031, + author="M. {Carugi (Ed.)} and D. {McDysan (Ed.)}", + title="{Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)}", + howpublished="RFC 4031 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4031", + pages="1--50", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4031.txt", + key="RFC 4031", + abstract={This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This memo provides information for the Internet community.}, + keywords="l3vpn, service provider, vpn", + doi="10.17487/RFC4031", + } + +@misc{rfc4032, + author="G. Camarillo and P. Kyzivat", + title="{Update to the Session Initiation Protocol (SIP) Preconditions Framework}", + howpublished="RFC 4032 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4032", + pages="1--10", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4032.txt", + key="RFC 4032", + abstract={This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS-TRACK]}, + keywords="qos, quality of service, precondition", + doi="10.17487/RFC4032", + } + +@misc{rfc4033, + author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose", + title="{DNS Security Introduction and Requirements}", + howpublished="RFC 4033 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4033", + pages="1--21", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6014, 6840", +url="https://www.rfc-editor.org/rfc/rfc4033.txt", + key="RFC 4033", + abstract={The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]}, + keywords="domain name system, authentication, origin integrity, dnssec, domain name system security extensions", + doi="10.17487/RFC4033", + } + +@misc{rfc4034, + author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose", + title="{Resource Records for the DNS Security Extensions}", + howpublished="RFC 4034 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4034", + pages="1--29", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4470, 6014, 6840, 6944", +url="https://www.rfc-editor.org/rfc/rfc4034.txt", + key="RFC 4034", + abstract={This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]}, + keywords="domain name system, authentication, origin integrity, dnssec, domain name system security extensions", + doi="10.17487/RFC4034", + } + +@misc{rfc4035, + author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose", + title="{Protocol Modifications for the DNS Security Extensions}", + howpublished="RFC 4035 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4035", + pages="1--53", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4470, 6014, 6840, 8198", +url="https://www.rfc-editor.org/rfc/rfc4035.txt", + key="RFC 4035", + abstract={This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]}, + keywords="domain name system, authentication, origin integrity, dnssec, domain name system security extensions", + doi="10.17487/RFC4035", + } + +@misc{rfc4036, + author="W. Sawyer", + title="{Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management}", + howpublished="RFC 4036 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4036", + pages="1--27", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4036.txt", + key="RFC 4036", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. [STANDARDS-TRACK]}, + keywords="mib, snmp, simple network management protocol", + doi="10.17487/RFC4036", + } + +@misc{rfc4037, + author="A. Rousskov", + title="{Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core}", + howpublished="RFC 4037 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4037", + pages="1--56", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4037.txt", + key="RFC 4037", + abstract={This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. [STANDARDS-TRACK]}, + keywords="callout server", + doi="10.17487/RFC4037", + } + +@misc{rfc4038, + author="M-K. {Shin (Ed.)} and Y-G. Hong and J. Hagino and P. Savola and E. M. Castro", + title="{Application Aspects of IPv6 Transition}", + howpublished="RFC 4038 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4038", + pages="1--33", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4038.txt", + key="RFC 4038", + abstract={As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. This memo provides information for the Internet community.}, + doi="10.17487/RFC4038", + } + +@misc{rfc4039, + author="S. Park and P. Kim and B. Volz", + title="{Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)}", + howpublished="RFC 4039 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4039", + pages="1--10", + year=2005, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4039.txt", + key="RFC 4039", + abstract={This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4039", + } + +@misc{rfc4040, + author="R. Kreuter", + title="{RTP Payload Format for a 64 kbit/s Transparent Call}", + howpublished="RFC 4040 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4040", + pages="1--8", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4040.txt", + key="RFC 4040", + abstract={This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called ``Clearmode''. It also serves as registration for a related MIME type called ``audio/clearmode''. ``Clearmode'' is a basic feature of VoIP Media Gateways. [STANDARDS-TRACK]}, + keywords="realtime transport protocol", + doi="10.17487/RFC4040", + } + +@misc{rfc4041, + author="A. Farrel", + title="{Requirements for Morality Sections in Routing Area Drafts}", + howpublished="RFC 4041 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4041", + pages="1--8", + year=2005, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4041.txt", + key="RFC 4041", + abstract={It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. 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.}, + keywords="moral values, moral code", + doi="10.17487/RFC4041", + } + +@misc{rfc4042, + author="M. Crispin", + title="{UTF-9 and UTF-18 Efficient Transformation Formats of Unicode}", + howpublished="RFC 4042 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4042", + pages="1--9", + year=2005, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4042.txt", + key="RFC 4042", + abstract={ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization. The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet. This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. This memo provides information for the Internet community.}, + keywords="universal character set, ucs, codeopints, unicode, utf-7, utf-8, utf-16", + doi="10.17487/RFC4042", + } + +@misc{rfc4043, + author="D. Pinkas and T. Gindin", + title="{Internet X.509 Public Key Infrastructure Permanent Identifier}", + howpublished="RFC 4043 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4043", + pages="1--15", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4043.txt", + key="RFC 4043", + abstract={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. 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. 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]}, + keywords="subjectAltName extension, dn", + doi="10.17487/RFC4043", + } + +@misc{rfc4044, + author="K. McCloghrie", + title="{Fibre Channel Management MIB}", + howpublished="RFC 4044 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4044", + pages="1--69", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4044.txt", + key="RFC 4044", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. [STANDARDS-TRACK]}, + keywords="management information base, fc-mgmt-mib", + doi="10.17487/RFC4044", + } + +@misc{rfc4045, + author="G. Bourdon", + title="{Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)}", + howpublished="RFC 4045 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4045", + pages="1--28", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4045.txt", + key="RFC 4045", + abstract={The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. This memo defines an Experimental Protocol for the Internet community.}, + keywords="ppp, point-to-point protocol", + doi="10.17487/RFC4045", + } + +@misc{rfc4046, + author="M. Baugher and R. Canetti and L. Dondeti and F. Lindholm", + title="{Multicast Security (MSEC) Group Key Management Architecture}", + howpublished="RFC 4046 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4046", + pages="1--38", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4046.txt", + key="RFC 4046", + abstract={This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community.}, + keywords="group security association, gsa", + doi="10.17487/RFC4046", + } + +@misc{rfc4047, + author="S. Allen and D. Wells", + title="{MIME Sub-type Registrations for Flexible Image Transport System (FITS)}", + howpublished="RFC 4047 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4047", + pages="1--23", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4047.txt", + key="RFC 4047", + abstract={This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. This memo provides information for the Internet community.}, + keywords="multipurpose internet mail extensions, astronomical observations", + doi="10.17487/RFC4047", + } + +@misc{rfc4048, + author="B. Carpenter", + title="{RFC 1888 Is Obsolete}", + howpublished="RFC 4048 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4048", + pages="1--4", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4548", +url="https://www.rfc-editor.org/rfc/rfc4048.txt", + key="RFC 4048", + abstract={This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community.}, + keywords="Internet, Protocol, Open, Systems, Interconnection", + doi="10.17487/RFC4048", + } + +@misc{rfc4049, + author="R. Housley", + title="{BinaryTime: An Alternate Format for Representing Date and Time in ASN.1}", + howpublished="RFC 4049 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4049", + pages="1--7", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6019", +url="https://www.rfc-editor.org/rfc/rfc4049.txt", + key="RFC 4049", + abstract={This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. This memo defines an Experimental Protocol for the Internet community.}, + keywords="signing-time attribute, cryptographic message syntax, cms, SignedData, AuthenticatedData", + doi="10.17487/RFC4049", + } + +@misc{rfc4050, + author="S. Blake-Wilson and G. Karlinger and T. Kobayashi and Y. Wang", + title="{Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures}", + howpublished="RFC 4050 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4050", + pages="1--19", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4050.txt", + key="RFC 4050", + abstract={This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. This memo provides information for the Internet community.}, + keywords="elliptic curve digital signature algorithm, ecdsa, elliptic curve cryptography, ecc, xml, digital signatures, xml dsig, xml", + doi="10.17487/RFC4050", + } + +@misc{rfc4051, + author="D. {Eastlake 3rd}", + title="{Additional XML Security Uniform Resource Identifiers (URIs)}", + howpublished="RFC 4051 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4051", + pages="1--17", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6931", +url="https://www.rfc-editor.org/rfc/rfc4051.txt", + key="RFC 4051", + abstract={A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information. [STANDARDS-TRACK]}, + keywords="digital signatures, encryption, canonicalization", + doi="10.17487/RFC4051", + } + +@misc{rfc4052, + author="L. {Daigle (Ed.)} and Internet Architecture Board", + title="{IAB Processes for Management of IETF Liaison Relationships}", + howpublished="RFC 4052 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4052", + pages="1--9", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4052.txt", + key="RFC 4052", + abstract={This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet architecture board, sdo, standards development organization", + doi="10.17487/RFC4052", + } + +@misc{rfc4053, + author="S. Trowbridge and S. Bradner and F. Baker", + title="{Procedures for Handling Liaison Statements to and from the IETF}", + howpublished="RFC 4053 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4053", + pages="1--19", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4053.txt", + key="RFC 4053", + abstract={This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. 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.}, + keywords="sdo, standards develoopment organization", + doi="10.17487/RFC4053", + } + +@misc{rfc4054, + author="J. {Strand (Ed.)} and A. {Chiu (Ed.)}", + title="{Impairments and Other Constraints on Optical Layer Routing}", + howpublished="RFC 4054 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4054", + pages="1--29", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4054.txt", + key="RFC 4054", + abstract={Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. This memo provides information for the Internet community.}, + keywords="diversity, routing, path selection, impariment, ase, pmd, optical control plane, gmpls", + doi="10.17487/RFC4054", + } + +@misc{rfc4055, + author="J. Schaad and B. Kaliski and R. Housley", + 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}", + howpublished="RFC 4055 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4055", + pages="1--25", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5756", +url="https://www.rfc-editor.org/rfc/rfc4055.txt", + key="RFC 4055", + abstract={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]}, + keywords="ASN.1, RSASSA-PSS, RSA probabilistic signature scheme, signature algorithm, RSAES-OAEP, RSA encryption scheme optimal asymmetric encryption padding, public-key cryptography standards, PKCS, pki", + doi="10.17487/RFC4055", + } + +@misc{rfc4056, + author="J. Schaad", + title="{Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 4056 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4056", + pages="1--6", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4056.txt", + key="RFC 4056", + abstract={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]}, + keywords="RSA probabilistic signature scheme, digital signature", + doi="10.17487/RFC4056", + } + +@misc{rfc4057, + author="J. {Bound (Ed.)}", + title="{IPv6 Enterprise Network Scenarios}", + howpublished="RFC 4057 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4057", + pages="1--17", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4057.txt", + key="RFC 4057", + abstract={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.}, + keywords="internet protocol version 6", + doi="10.17487/RFC4057", + } + +@misc{rfc4058, + author="A. {Yegin (Ed.)} and Y. Ohba and R. Penno and G. Tsirtsis and C. Wang", + title="{Protocol for Carrying Authentication for Network Access (PANA) Requirements}", + howpublished="RFC 4058 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4058", + pages="1--19", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4058.txt", + key="RFC 4058", + abstract={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.}, + keywords="network connectivity, link layer agnostic protocol", + doi="10.17487/RFC4058", + } + +@misc{rfc4059, + author="D. Linsenbardt and S. Pontius and A. Sturgeon", + title="{Internet X.509 Public Key Infrastructure Warranty Certificate Extension}", + howpublished="RFC 4059 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4059", + pages="1--9", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4059.txt", + key="RFC 4059", + abstract={This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This memo provides information for the Internet community.}, + keywords="certificate authority, ca, insurance policy", + doi="10.17487/RFC4059", + } + +@misc{rfc4060, + author="Q. Xie and D. Pearce", + 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}", + howpublished="RFC 4060 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4060", + pages="1--19", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4060.txt", + key="RFC 4060", + abstract={This document specifies RTP payload formats for encapsulating European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]}, + keywords="real-time transport protocol, dsr, distributed speeech recognition, xfe, extended front-end, xafe, extended advanced front-end", + doi="10.17487/RFC4060", + } + +@misc{rfc4061, + author="V. Manral and R. White and A. Shaikh", + title="{Benchmarking Basic OSPF Single Router Control Plane Convergence}", + howpublished="RFC 4061 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4061", + pages="1--16", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4061.txt", + key="RFC 4061", + abstract={This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance. NOTE: In this document, the word ``convergence'' relates to single router control plane convergence only. This memo provides information for the Internet community.}, + keywords="spf time, adjacency formation time", + doi="10.17487/RFC4061", + } + +@misc{rfc4062, + author="V. Manral and R. White and A. Shaikh", + title="{OSPF Benchmarking Terminology and Concepts}", + howpublished="RFC 4062 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4062", + pages="1--9", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4062.txt", + key="RFC 4062", + abstract={This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. This memo provides information for the Internet community.}, + keywords="spf time, adjacency formation time", + doi="10.17487/RFC4062", + } + +@misc{rfc4063, + author="V. Manral and R. White and A. Shaikh", + title="{Considerations When Using Basic OSPF Convergence Benchmarks}", + howpublished="RFC 4063 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4063", + pages="1--11", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4063.txt", + key="RFC 4063", + abstract={This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. This memo provides information for the Internet community.}, + keywords="spf time, adjacency formation time", + doi="10.17487/RFC4063", + } + +@misc{rfc4064, + author="A. Patel and K. Leung", + title="{Experimental Message, Extensions, and Error Codes for Mobile IPv4}", + howpublished="RFC 4064 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4064", + pages="1--11", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4064.txt", + key="RFC 4064", + abstract={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]}, + keywords="internet protocol, message types", + doi="10.17487/RFC4064", + } + +@misc{rfc4065, + author="J. Kempf", + title="{Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations}", + howpublished="RFC 4065 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4065", + pages="1--8", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4065.txt", + key="RFC 4065", + abstract={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.}, + keywords="candidate access router discovery, card, context transfer protocol, CXTP, ICMP", + doi="10.17487/RFC4065", + } + +@misc{rfc4066, + author="M. {Liebsch (Ed.)} and A. {Singh (Ed.)} and H. Chaskar and D. Funato and E. Shim", + title="{Candidate Access Router Discovery (CARD)}", + howpublished="RFC 4066 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4066", + pages="1--46", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4066.txt", + key="RFC 4066", + abstract={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.}, + keywords="mobile node, mn, cars, candidate ars", + doi="10.17487/RFC4066", + } + +@misc{rfc4067, + author="J. {Loughney (Ed.)} and M. Nakhjiri and C. Perkins and R. Koodli", + title="{Context Transfer Protocol (CXTP)}", + howpublished="RFC 4067 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4067", + pages="1--33", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4067.txt", + key="RFC 4067", + abstract={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.}, + keywords="mobile node, mn", + doi="10.17487/RFC4067", + } + +@misc{rfc4068, + author="R. {Koodli (Ed.)}", + title="{Fast Handovers for Mobile IPv6}", + howpublished="RFC 4068 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4068", + pages="1--42", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5268", +url="https://www.rfc-editor.org/rfc/rfc4068.txt", + key="RFC 4068", + abstract={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.}, + keywords="internet protocol version 6, access router, mobile node, mn", + doi="10.17487/RFC4068", + } + +@misc{rfc4069, + author="M. Dodge and B. Ray", + title="{Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding}", + howpublished="RFC 4069 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4069", + pages="1--19", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4069.txt", + key="RFC 4069", + abstract={This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]}, + keywords="mib, management information base, VDSL-LINE-MIB, VDSL-LINE-EXT-SCM-MIB", + doi="10.17487/RFC4069", + } + +@misc{rfc4070, + author="M. Dodge and B. Ray", + title="{Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding}", + howpublished="RFC 4070 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4070", + pages="1--24", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4070.txt", + key="RFC 4070", + abstract={This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]}, + keywords="management information base, mib, VDSL-LINE-MIB, VDSL-LINE-EXT-MCM-MIB", + doi="10.17487/RFC4070", + } + +@misc{rfc4071, + author="R. {Austein (Ed.)} and B. {Wijnen (Ed.)}", + title="{Structure of the IETF Administrative Support Activity (IASA)}", + howpublished="RFC 4071 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4071", + pages="1--20", + year=2005, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4371, 7691", +url="https://www.rfc-editor.org/rfc/rfc4071.txt", + key="RFC 4071", + abstract={This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="isoc, ietf administrative oversight committee, IAOC, ietf administrative director, iad", + doi="10.17487/RFC4071", + } + +@misc{rfc4072, + author="P. {Eronen (Ed.)} and T. Hiller and G. Zorn", + title="{Diameter Extensible Authentication Protocol (EAP) Application}", + howpublished="RFC 4072 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4072", + pages="1--33", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7268, 8044", +url="https://www.rfc-editor.org/rfc/rfc4072.txt", + key="RFC 4072", + abstract={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]}, + keywords="command codes, avp, nas, network access server, back-end autentication server", + doi="10.17487/RFC4072", + } + +@misc{rfc4073, + author="R. Housley", + title="{Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 4073 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4073", + pages="1--9", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4073.txt", + key="RFC 4073", + abstract={This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]}, + keywords="content collection", + doi="10.17487/RFC4073", + } + +@misc{rfc4074, + author="Y. Morishita and T. Jinmei", + title="{Common Misbehavior Against DNS Queries for IPv6 Addresses}", + howpublished="RFC 4074 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4074", + pages="1--6", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4074.txt", + key="RFC 4074", + abstract={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.}, + keywords="resource records, aaaa, domain name service", + doi="10.17487/RFC4074", + } + +@misc{rfc4075, + author="V. Kalusivalingam", + title="{Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6}", + howpublished="RFC 4075 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4075", + pages="1--5", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4075.txt", + key="RFC 4075", + abstract={This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]}, + keywords="dynamic host configuration protocol, server addresses", + doi="10.17487/RFC4075", + } + +@misc{rfc4076, + author="T. Chown and S. Venaas and A. Vijayabhaskar", + title="{Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}", + howpublished="RFC 4076 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4076", + pages="1--8", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4076.txt", + key="RFC 4076", + abstract={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.}, + keywords="internet protocol, stateless address autoconfiguration", + doi="10.17487/RFC4076", + } + +@misc{rfc4077, + author="A.B. Roach", + title="{A Negative Acknowledgement Mechanism for Signaling Compression}", + howpublished="RFC 4077 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4077", + pages="1--16", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4077.txt", + key="RFC 4077", + abstract={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]}, + keywords="sigcomp, negative feedback", + doi="10.17487/RFC4077", + } + +@misc{rfc4078, + author="N. Earnshaw and S. Aoki and A. Ashley and W. Kameyama", + title="{The TV-Anytime Content Reference Identifier (CRID)}", + howpublished="RFC 4078 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4078", + pages="1--10", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4078.txt", + key="RFC 4078", + abstract={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. 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. 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.}, + keywords="digital broadcasting, tv, radio, uri, uniform resource identifier, content referencing, storage systems", + doi="10.17487/RFC4078", + } + +@misc{rfc4079, + author="J. Peterson", + title="{A Presence Architecture for the Distribution of GEOPRIV Location Objects}", + howpublished="RFC 4079 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4079", + pages="1--7", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4079.txt", + key="RFC 4079", + abstract={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.}, + keywords="using protocol", + doi="10.17487/RFC4079", + } + +@misc{rfc4080, + author="R. Hancock and G. Karagiannis and J. Loughney and S. Van den Bosch", + title="{Next Steps in Signaling (NSIS): Framework}", + howpublished="RFC 4080 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4080", + pages="1--49", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4080.txt", + key="RFC 4080", + abstract={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. 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.}, + keywords="data flow, architectural framework, signaling protocols, signaling application", + doi="10.17487/RFC4080", + } + +@misc{rfc4081, + author="H. Tschofenig and D. Kroeselberg", + title="{Security Threats for Next Steps in Signaling (NSIS)}", + howpublished="RFC 4081 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4081", + pages="1--28", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4081.txt", + key="RFC 4081", + abstract={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.}, + doi="10.17487/RFC4081", + } + +@misc{rfc4082, + author="A. Perrig and D. Song and R. Canetti and J. D. Tygar and B. Briscoe", + title="{Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction}", + howpublished="RFC 4082 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4082", + pages="1--22", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4082.txt", + key="RFC 4082", + abstract={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. 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.}, + keywords="data streams", + doi="10.17487/RFC4082", + } + +@misc{rfc4083, + author="M. Garcia-Martin", + title="{Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)}", + howpublished="RFC 4083 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4083", + pages="1--36", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4083.txt", + key="RFC 4083", + abstract={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.}, + keywords="3GPP IP multimedia core network subsystem, ims, cellular networks", + doi="10.17487/RFC4083", + } + +@misc{rfc4084, + author="J. Klensin", + title="{Terminology for Describing Internet Connectivity}", + howpublished="RFC 4084 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4084", + pages="1--11", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4084.txt", + key="RFC 4084", + abstract={As the Internet has evolved, many types of arrangements have been advertised and sold as ``Internet connectivity''. Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="", + doi="10.17487/RFC4084", + } + +@misc{rfc4085, + author="D. Plonka", + title="{Embedding Globally-Routable Internet Addresses Considered Harmful}", + howpublished="RFC 4085 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4085", + pages="1--10", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4085.txt", + key="RFC 4085", + abstract={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.}, + keywords="", + doi="10.17487/RFC4085", + } + +@misc{rfc4086, + author="D. {Eastlake 3rd} and J. Schiller and S. Crocker", + title="{Randomness Requirements for Security}", + howpublished="RFC 4086 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4086", + pages="1--48", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4086.txt", + key="RFC 4086", + abstract={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. 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 provid es 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.}, + keywords="cryptographic algorithms, passwords, cryptographic keys, pseudo-random, random, numbers, seed", + doi="10.17487/RFC4086", + } + +@misc{rfc4087, + author="D. Thaler", + title="{IP Tunnel MIB}", + howpublished="RFC 4087 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4087", + pages="1--25", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4087.txt", + key="RFC 4087", + abstract={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]}, + keywords="management information base, internet protocol, tunnel-mib", + doi="10.17487/RFC4087", + } + +@misc{rfc4088, + author="D. Black and K. McCloghrie and J. Schoenwaelder", + title="{Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 4088 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4088", + pages="1--18", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4088.txt", + key="RFC 4088", + abstract={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. 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]}, + keywords="uri, uniform resource identifiers, snmp-uri", + doi="10.17487/RFC4088", + } + +@misc{rfc4089, + author="S. {Hollenbeck (Ed.)} and IAB and IESG", + title="{IAB and IESG Recommendation for IETF Administrative Restructuring}", + howpublished="RFC 4089 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4089", + pages="1--55", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4089.txt", + key="RFC 4089", + abstract={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.}, + keywords="internet architecture board, internet engineering steering group, internet engineering task force", + doi="10.17487/RFC4089", + } + +@misc{rfc4090, + author="P. {Pan (Ed.)} and G. {Swallow (Ed.)} and A. {Atlas (Ed.)}", + title="{Fast Reroute Extensions to RSVP-TE for LSP Tunnels}", + howpublished="RFC 4090 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4090", + pages="1--38", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8271", +url="https://www.rfc-editor.org/rfc/rfc4090.txt", + key="RFC 4090", + abstract={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. 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]}, + keywords="resource reservation protocol, traffic engineering, lsp, label switch path, one-to-one backup, facility backup", + doi="10.17487/RFC4090", + } + +@misc{rfc4091, + author="G. Camarillo and J. Rosenberg", + title="{The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework}", + howpublished="RFC 4091 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4091", + pages="1--7", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5245", +url="https://www.rfc-editor.org/rfc/rfc4091.txt", + key="RFC 4091", + abstract={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]}, + keywords="", + doi="10.17487/RFC4091", + } + +@misc{rfc4092, + author="G. Camarillo and J. Rosenberg", + title="{Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)}", + howpublished="RFC 4092 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4092", + pages="1--6", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5245", +url="https://www.rfc-editor.org/rfc/rfc4092.txt", + key="RFC 4092", + abstract={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]}, + keywords="sdp-anat, option-tag", + doi="10.17487/RFC4092", + } + +@misc{rfc4093, + author="F. {Adrangi (Ed.)} and H. {Levkowetz (Ed.)}", + title="{Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways}", + howpublished="RFC 4093 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4093", + pages="1--19", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4093.txt", + key="RFC 4093", + abstract={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.}, + doi="10.17487/RFC4093", + } + +@misc{rfc4094, + author="J. Manner and X. Fu", + title="{Analysis of Existing Quality-of-Service Signaling Protocols}", + howpublished="RFC 4094 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4094", + pages="1--45", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4094.txt", + key="RFC 4094", + abstract={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.}, + keywords="qos, quality of service, rsvp, nsis, yessir, boomerang, daris, insignia, bgrp, sicap, mobility, performance, security", + doi="10.17487/RFC4094", + } + +@misc{rfc4095, + author="C. Malamud", + title="{Attaching Meaning to Solicitation Class Keywords}", + howpublished="RFC 4095 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4095", + pages="1--11", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4095.txt", + key="RFC 4095", + abstract={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. 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 informa tion about the ``org.example.adv'' solicitation class keyword. [STANDARDS-TRACK]}, + keywords="uri, uniform resource identifier, no soliciting smtp service extension, esmtp service extension, dynamic delegation discovery system, ddds, no-solicit", + doi="10.17487/RFC4095", + } + +@misc{rfc4096, + author="C. Malamud", + title="{Policy-Mandated Labels Such as ``Adv:'' in Email Subject Headers Considered Ineffective At Best}", + howpublished="RFC 4096 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4096", + pages="1--14", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4096.txt", + key="RFC 4096", + abstract={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.}, + doi="10.17487/RFC4096", + } + +@misc{rfc4097, + author="M. {Barnes (Ed.)}", + title="{Middlebox Communications (MIDCOM) Protocol Evaluation}", + howpublished="RFC 4097 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4097", + pages="1--44", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4097.txt", + key="RFC 4097", + abstract={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.}, + keywords="snmp, simple network management protocol, rsip, realm specific internet protocol, megaco, diameter, cops, common open policy service", + doi="10.17487/RFC4097", + } + +@misc{rfc4098, + author="H. Berkowitz and E. {Davies (Ed.)} and S. Hares and P. Krishnaswamy and M. Lepp", + title="{Terminology for Benchmarking BGP Device Convergence in the Control Plane}", + howpublished="RFC 4098 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4098", + pages="1--36", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4098.txt", + key="RFC 4098", + abstract={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.}, + keywords="border gateway protocol, benchmarking methodology, ebgp", + doi="10.17487/RFC4098", + } + +@misc{rfc4101, + author="E. Rescorla and IAB", + title="{Writing Protocol Models}", + howpublished="RFC 4101 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4101", + pages="1--22", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4101.txt", + key="RFC 4101", + abstract={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.}, + keywords="document review", + doi="10.17487/RFC4101", + } + +@misc{rfc4102, + author="P. Jones", + title="{Registration of the text/red MIME Sub-Type}", + howpublished="RFC 4102 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4102", + pages="1--6", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6354", +url="https://www.rfc-editor.org/rfc/rfc4102.txt", + key="RFC 4102", + abstract={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]}, + keywords="rtp, real-time transport protocol", + doi="10.17487/RFC4102", + } + +@misc{rfc4103, + author="G. Hellstrom and P. Jones", + title="{RTP Payload for Text Conversation}", + howpublished="RFC 4103 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4103", + pages="1--20", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4103.txt", + key="RFC 4103", + abstract={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. One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text. 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]}, + keywords="real-time, applications, video, audio, packets", + doi="10.17487/RFC4103", + } + +@misc{rfc4104, + author="M. {Pana (Ed.)} and A. Reyes and A. Barba and D. Moron and M. Brunner", + title="{Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)}", + howpublished="RFC 4104 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4104", + pages="1--88", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4104.txt", + key="RFC 4104", + abstract={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]}, + keywords="policy core lightweight directory access protocol, pcim, policy core information model, mapping classes", + doi="10.17487/RFC4104", + } + +@misc{rfc4105, + author="J.-L. Le {Roux (Ed.)} and J.-P. {Vasseur (Ed.)} and J. {Boyle (Ed.)}", + title="{Requirements for Inter-Area MPLS Traffic Engineering}", + howpublished="RFC 4105 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4105", + pages="1--22", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4105.txt", + key="RFC 4105", + abstract={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.}, + keywords="multiprotocol label switching, mpls-te, mpls te", + doi="10.17487/RFC4105", + } + +@misc{rfc4106, + author="J. Viega and D. McGrew", + title="{The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)}", + howpublished="RFC 4106 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4106", + pages="1--11", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4106.txt", + key="RFC 4106", + abstract={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]}, + keywords="aes, advanced encryption standard", + doi="10.17487/RFC4106", + } + +@misc{rfc4107, + author="S. Bellovin and R. Housley", + title="{Guidelines for Cryptographic Key Management}", + howpublished="RFC 4107 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4107", + pages="1--7", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4107.txt", + key="RFC 4107", + abstract={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.}, + keywords="automated key management, manual key management", + doi="10.17487/RFC4107", + } + +@misc{rfc4108, + author="R. Housley", + title="{Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages}", + howpublished="RFC 4108 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4108", + pages="1--61", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4108.txt", + key="RFC 4108", + abstract={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]}, + keywords="hardward module components, digital signature", + doi="10.17487/RFC4108", + } + +@misc{rfc4109, + author="P. Hoffman", + title="{Algorithms for Internet Key Exchange version 1 (IKEv1)}", + howpublished="RFC 4109 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4109", + pages="1--5", + year=2005, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4109.txt", + key="RFC 4109", + abstract={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]}, + keywords="ike, ipsec, oakley, authentication, isakmp, internet security key management", + doi="10.17487/RFC4109", + } + +@misc{rfc4110, + author="R. Callon and M. Suzuki", + title="{A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)}", + howpublished="RFC 4110 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4110", + pages="1--82", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4110.txt", + key="RFC 4110", + abstract={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.}, + doi="10.17487/RFC4110", + } + +@misc{rfc4111, + author="L. {Fang (Ed.)}", + title="{Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)}", + howpublished="RFC 4111 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4111", + pages="1--45", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4111.txt", + key="RFC 4111", + abstract={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.}, + doi="10.17487/RFC4111", + } + +@misc{rfc4112, + author="D. {Eastlake 3rd}", + title="{Electronic Commerce Modeling Language (ECML) Version 2 Specification}", + howpublished="RFC 4112 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4112", + pages="1--34", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4112.txt", + key="RFC 4112", + abstract={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]}, + keywords="", + doi="10.17487/RFC4112", + } + +@misc{rfc4113, + author="B. Fenner and J. Flick", + title="{Management Information Base for the User Datagram Protocol (UDP)}", + howpublished="RFC 4113 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4113", + pages="1--19", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4113.txt", + key="RFC 4113", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]}, + keywords="MIB-UDP, mib, UDP-MIB, internet protocol, ip", + doi="10.17487/RFC4113", + } + +@misc{rfc4114, + author="S. Hollenbeck", + title="{E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 4114 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4114", + pages="1--17", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4114.txt", + key="RFC 4114", + abstract={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]}, + keywords="shared central repository", + doi="10.17487/RFC4114", + } + +@misc{rfc4115, + author="O. Aboul-Magd and S. Rabie", + title="{A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic}", + howpublished="RFC 4115 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4115", + pages="1--6", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4115.txt", + key="RFC 4115", + abstract={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.}, + keywords="data services, service scenarios, metering algorithm, color-blind, color-aware", + doi="10.17487/RFC4115", + } + +@misc{rfc4116, + author="J. Abley and K. Lindqvist and E. Davies and B. Black and V. Gill", + title="{IPv4 Multihoming Practices and Limitations}", + howpublished="RFC 4116 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4116", + pages="1--13", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4116.txt", + key="RFC 4116", + abstract={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.}, + keywords="internet protocol", + doi="10.17487/RFC4116", + } + +@misc{rfc4117, + author="G. Camarillo and E. Burger and H. Schulzrinne and A. van Wijk", + title="{Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)}", + howpublished="RFC 4117 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4117", + pages="1--19", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4117.txt", + key="RFC 4117", + abstract={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.}, + keywords="deaf, hard of hearing, speech-impaired, hearing-impaired", + doi="10.17487/RFC4117", + } + +@misc{rfc4118, + author="L. Yang and P. Zerfos and E. Sadot", + title="{Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)}", + howpublished="RFC 4118 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4118", + pages="1--41", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4118.txt", + key="RFC 4118", + abstract={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.}, + keywords="IEEE 802.11, wireless lan", + doi="10.17487/RFC4118", + } + +@misc{rfc4119, + author="J. Peterson", + title="{A Presence-based GEOPRIV Location Object Format}", + howpublished="RFC 4119 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4119", + pages="1--24", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5139, 5491, 7459", +url="https://www.rfc-editor.org/rfc/rfc4119.txt", + key="RFC 4119", + abstract={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]}, + keywords="pidf, presence information data format", + doi="10.17487/RFC4119", + } + +@misc{rfc4120, + author="C. Neuman and T. Yu and S. Hartman and K. Raeburn", + title="{The Kerberos Network Authentication Service (V5)}", + howpublished="RFC 4120 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4120", + pages="1--138", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4537, 5021, 5896, 6111, 6112, 6113, 6649, 6806, 7751, 8062, 8129", +url="https://www.rfc-editor.org/rfc/rfc4120.txt", + key="RFC 4120", + abstract={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]}, + keywords="KERBEROS, CAT,Security", + doi="10.17487/RFC4120", + } + +@misc{rfc4121, + author="L. Zhu and K. Jaganathan and S. Hartman", + title="{The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2}", + howpublished="RFC 4121 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4121", + pages="1--20", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6112, 6542, 6649, 8062", +url="https://www.rfc-editor.org/rfc/rfc4121.txt", + key="RFC 4121", + abstract={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. 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]}, + keywords="GSSAPI-KER, cryptosystem", + doi="10.17487/RFC4121", + } + +@misc{rfc4122, + author="P. Leach and M. Mealling and R. Salz", + title="{A Universally Unique IDentifier (UUID) URN Namespace}", + howpublished="RFC 4122 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4122", + pages="1--32", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4122.txt", + key="RFC 4122", + abstract={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. 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]}, + keywords="uniform resource name, guid, globally unique identifier", + doi="10.17487/RFC4122", + } + +@misc{rfc4123, + author="H. Schulzrinne and C. Agboh", + title="{Session Initiation Protocol (SIP)-H.323 Interworking Requirements}", + howpublished="RFC 4123 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4123", + pages="1--16", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4123.txt", + key="RFC 4123", + abstract={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.}, + keywords="SIP-H.323 IWF", + doi="10.17487/RFC4123", + } + +@misc{rfc4124, + author="F. Le {Faucheur (Ed.)}", + title="{Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering}", + howpublished="RFC 4124 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4124", + pages="1--37", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4124.txt", + key="RFC 4124", + abstract={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]}, + keywords="DS-TE, igp, interior gateway protocol, extensions, rsvp, resource reservation protocol", + doi="10.17487/RFC4124", + } + +@misc{rfc4125, + author="F. Le Faucheur and W. Lai", + title="{Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering}", + howpublished="RFC 4125 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4125", + pages="1--12", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4125.txt", + key="RFC 4125", + abstract={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.}, + keywords="ds-te, maximum allocation model", + doi="10.17487/RFC4125", + } + +@misc{rfc4126, + author="J. Ash", + title="{Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering \& Performance Comparisons}", + howpublished="RFC 4126 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4126", + pages="1--22", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4126.txt", + key="RFC 4126", + abstract={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.}, + keywords="diffserv-enabled mpls traffic engineering, ds-te, mar, bandwidth reservation, bandwidth allocation, bandwidth protection, performance evaluation, cac, network model", + doi="10.17487/RFC4126", + } + +@misc{rfc4127, + author="F. Le {Faucheur (Ed.)}", + title="{Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering}", + howpublished="RFC 4127 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4127", + pages="1--13", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4127.txt", + key="RFC 4127", + abstract={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.}, + keywords="ds-te, russian dolls model, multi-protocol label switching", + doi="10.17487/RFC4127", + } + +@misc{rfc4128, + author="W. Lai", + title="{Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation}", + howpublished="RFC 4128 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4128", + pages="1--25", + year=2005, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4128.txt", + key="RFC 4128", + abstract={``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.}, + keywords="label switched path, lsp, lsp blocking, lsp preemption, lsp priority traffic overload, bandwidth efficiency, bandwidth sharing, bandwidth protection, class isolation, maximum allocation model, russian dolls model", + doi="10.17487/RFC4128", + } + +@misc{rfc4129, + author="R. Mukundan and K. Morneault and N. Mangalpally", + title="{Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol}", + howpublished="RFC 4129 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4129", + pages="1--15", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4129.txt", + key="RFC 4129", + abstract={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]}, + keywords="backhauling, isdn user adaptation, pbx, private branch exchanges", + doi="10.17487/RFC4129", + } + +@misc{rfc4130, + author="D. Moberg and R. Drummond", + title="{MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)}", + howpublished="RFC 4130 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4130", + pages="1--47", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4130.txt", + key="RFC 4130", + abstract={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]}, + keywords="hyper text transfer protocol, simple mail transfer protocol", + doi="10.17487/RFC4130", + } + +@misc{rfc4131, + author="S. Green and K. Ozawa and E. {Cardona (Ed.)} and A. Katsnelson", + title="{Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus}", + howpublished="RFC 4131 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4131", + pages="1--85", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4131.txt", + key="RFC 4131", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of 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]}, + keywords="mib, snmp, simple network management protocol, docs-ietf-bpi2-mib", + doi="10.17487/RFC4131", + } + +@misc{rfc4132, + author="S. Moriai and A. Kato and M. Kanda", + title="{Addition of Camellia Cipher Suites to Transport Layer Security (TLS)}", + howpublished="RFC 4132 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4132", + pages="1--7", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5932", +url="https://www.rfc-editor.org/rfc/rfc4132.txt", + key="RFC 4132", + abstract={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]}, + keywords="camellia encryption algorithm", + doi="10.17487/RFC4132", + } + +@misc{rfc4133, + author="A. Bierman and K. McCloghrie", + title="{Entity MIB (Version 3)}", + howpublished="RFC 4133 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4133", + pages="1--62", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6933", +url="https://www.rfc-editor.org/rfc/rfc4133.txt", + key="RFC 4133", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). [STANDARDS-TRACK]}, + keywords="management information base, snmp, simple network management protocol", + doi="10.17487/RFC4133", + } + +@misc{rfc4134, + author="P. {Hoffman (Ed.)}", + title="{Examples of S/MIME Messages}", + howpublished="RFC 4134 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4134", + pages="1--136", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4134.txt", + key="RFC 4134", + abstract={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.}, + doi="10.17487/RFC4134", + } + +@misc{rfc4135, + author="JH. Choi and G. Daley", + title="{Goals of Detecting Network Attachment in IPv6}", + howpublished="RFC 4135 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4135", + pages="1--9", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4135.txt", + key="RFC 4135", + abstract={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.}, + keywords="dna, detecting attachment links, change detection", + doi="10.17487/RFC4135", + } + +@misc{rfc4136, + author="P. Pillay-Esnault", + title="{OSPF Refresh and Flooding Reduction in Stable Topologies}", + howpublished="RFC 4136 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4136", + pages="1--5", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4136.txt", + key="RFC 4136", + abstract={This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies. 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.}, + keywords="open shortest path first, link state advertisement, lsa, donotage", + doi="10.17487/RFC4136", + } + +@misc{rfc4137, + author="J. Vollbrecht and P. Eronen and N. Petroni and Y. Ohba", + title="{State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator}", + howpublished="RFC 4137 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4137", + pages="1--51", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4137.txt", + key="RFC 4137", + abstract={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. 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. 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.}, + keywords="eap stand-alone authenticator, eap backend authenticator, eap full authenticator", + doi="10.17487/RFC4137", + } + +@misc{rfc4138, + author="P. Sarolahti and M. Kojo", + title="{Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)}", + howpublished="RFC 4138 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4138", + pages="1--23", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5682", +url="https://www.rfc-editor.org/rfc/rfc4138.txt", + key="RFC 4138", + abstract={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.}, + keywords="tcp, transmission control protocol", + doi="10.17487/RFC4138", + } + +@misc{rfc4139, + author="D. Papadimitriou and J. Drake and J. Ash and A. Farrel and L. Ong", + title="{Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)}", + howpublished="RFC 4139 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4139", + pages="1--16", + year=2005, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4139.txt", + key="RFC 4139", + abstract={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). 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.}, + keywords="tdm, otn, control plane, call, connection", + doi="10.17487/RFC4139", + } + +@misc{rfc4140, + author="H. Soliman and C. Castelluccia and K. El Malki and L. Bellier", + title="{Hierarchical Mobile IPv6 Mobility Management (HMIPv6)}", + howpublished="RFC 4140 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4140", + pages="1--29", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5380", +url="https://www.rfc-editor.org/rfc/rfc4140.txt", + key="RFC 4140", + abstract={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.}, + keywords="internet protocol version 6, neighbour discovery, neighbor discovery, mobility anchor point, map", + doi="10.17487/RFC4140", + } + +@misc{rfc4141, + author="K. Toyoda and D. Crocker", + title="{SMTP and MIME Extensions for Content Conversion}", + howpublished="RFC 4141 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4141", + pages="1--26", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4141.txt", + key="RFC 4141", + abstract={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]}, + keywords="esmtp, simple mail transfer protocol, extended simple mail transfer protocol, multipurpose internet mail extensions", + doi="10.17487/RFC4141", + } + +@misc{rfc4142, + author="D. Crocker and G. Klyne", + title="{Full-mode Fax Profile for Internet Mail (FFPIM)}", + howpublished="RFC 4142 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4142", + pages="1--9", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4142.txt", + key="RFC 4142", + abstract={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]}, + keywords="facsimile, full mode, internet mail", + doi="10.17487/RFC4142", + } + +@misc{rfc4143, + author="K. Toyoda and D. Crocker", + title="{Facsimile Using Internet Mail (IFAX) Service of ENUM}", + howpublished="RFC 4143 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4143", + pages="1--5", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4143.txt", + key="RFC 4143", + abstract={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]}, + keywords="naptr, enum naming authority pointer, facsimile using internet mail, dns, domain name system", + doi="10.17487/RFC4143", + } + +@misc{rfc4144, + author="D. {Eastlake 3rd}", + title="{How to Gain Prominence and Influence in Standards Organizations}", + howpublished="RFC 4144 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4144", + pages="1--9", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4144.txt", + key="RFC 4144", + abstract={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.}, + doi="10.17487/RFC4144", + } + +@misc{rfc4145, + author="D. Yon and G. Camarillo", + title="{TCP-Based Media Transport in the Session Description Protocol (SDP)}", + howpublished="RFC 4145 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4145", + pages="1--15", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4572", +url="https://www.rfc-editor.org/rfc/rfc4145.txt", + key="RFC 4145", + abstract={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]}, + keywords="setup, connection, reestablishment", + doi="10.17487/RFC4145", + } + +@misc{rfc4146, + author="R. Gellens", + title="{Simple New Mail Notification}", + howpublished="RFC 4146 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4146", + pages="1--5", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4146.txt", + key="RFC 4146", + abstract={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. 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.}, + keywords="mail client, nm\_notifyuser", + doi="10.17487/RFC4146", + } + +@misc{rfc4147, + author="G. Huston", + title="{Proposed Changes to the Format of the IANA IPv6 Registry}", + howpublished="RFC 4147 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4147", + pages="1--10", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4147.txt", + key="RFC 4147", + abstract={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.}, + keywords="internet protocol version 6, address format, address architecture", + doi="10.17487/RFC4147", + } + +@misc{rfc4148, + author="E. Stephan", + title="{IP Performance Metrics (IPPM) Metrics Registry}", + howpublished="RFC 4148 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4148", + pages="1--14", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6248", +url="https://www.rfc-editor.org/rfc/rfc4148.txt", + key="RFC 4148", + abstract={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. 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. 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.}, + keywords="internet protocol, object identities, iana-ippm-metrics-registry-mib", + doi="10.17487/RFC4148", + } + +@misc{rfc4149, + author="C. Kalbfleisch and R. Cole and D. Romascanu", + title="{Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms}", + howpublished="RFC 4149 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4149", + pages="1--39", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4149.txt", + key="RFC 4149", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]}, + keywords="sspm, mib, management information base, sspm mib", + doi="10.17487/RFC4149", + } + +@misc{rfc4150, + author="R. Dietz and R. Cole", + title="{Transport Performance Metrics MIB}", + howpublished="RFC 4150 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4150", + pages="1--57", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4150.txt", + key="RFC 4150", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring 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]}, + keywords="managgement information base, tpm, tpm-mib", + doi="10.17487/RFC4150", + } + +@misc{rfc4151, + author="T. Kindberg and S. Hawke", + title="{The 'tag' URI Scheme}", + howpublished="RFC 4151 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4151", + pages="1--11", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4151.txt", + key="RFC 4151", + abstract={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.}, + keywords="uniform resource identifier, entity identifier", + doi="10.17487/RFC4151", + } + +@misc{rfc4152, + author="K. Tesink and R. Fox", + title="{A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code}", + howpublished="RFC 4152 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4152", + pages="1--7", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4152.txt", + key="RFC 4152", + abstract={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.}, + keywords="ansi, ansi t1.213", + doi="10.17487/RFC4152", + } + +@misc{rfc4153, + author="K. Fujimura and M. Terada and D. {Eastlake 3rd}", + title="{XML Voucher: Generic Voucher Language}", + howpublished="RFC 4153 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4153", + pages="1--21", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4153.txt", + key="RFC 4153", + abstract={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.}, + keywords="extensible markup language, logical entity", + doi="10.17487/RFC4153", + } + +@misc{rfc4154, + author="M. Terada and K. Fujimura", + title="{Voucher Trading System Application Programming Interface (VTS-API)}", + howpublished="RFC 4154 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4154", + pages="1--32", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4154.txt", + key="RFC 4154", + abstract={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.}, + keywords="wallet, transfer, redeem", + doi="10.17487/RFC4154", + } + +@misc{rfc4155, + author="E. Hall", + title="{The application/mbox Media Type}", + howpublished="RFC 4155 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4155", + pages="1--9", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4155.txt", + key="RFC 4155", + abstract={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.}, + keywords="mbox database", + doi="10.17487/RFC4155", + } + +@misc{rfc4156, + author="P. Hoffman", + title="{The wais URI Scheme}", + howpublished="RFC 4156 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4156", + pages="1--4", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4156.txt", + key="RFC 4156", + abstract={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.}, + keywords="uniform resource identifier", + doi="10.17487/RFC4156", + } + +@misc{rfc4157, + author="P. Hoffman", + title="{The prospero URI Scheme}", + howpublished="RFC 4157 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4157", + pages="1--4", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4157.txt", + key="RFC 4157", + abstract={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.}, + keywords="uniform resource identifier", + doi="10.17487/RFC4157", + } + +@misc{rfc4158, + author="M. Cooper and Y. Dzambasow and P. Hesse and S. Joseph and R. Nicholas", + title="{Internet X.509 Public Key Infrastructure: Certification Path Building}", + howpublished="RFC 4158 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4158", + pages="1--81", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4158.txt", + key="RFC 4158", + abstract={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.}, + keywords="certification path discovery, path discovery, certificate path building, certificate path discovery", + doi="10.17487/RFC4158", + } + +@misc{rfc4159, + author="G. Huston", + title="{Deprecation of ``ip6.int''}", + howpublished="RFC 4159 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4159", + pages="1--3", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4159.txt", + key="RFC 4159", + abstract={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.}, + keywords="ipv6, dns, domain name system", + doi="10.17487/RFC4159", + } + +@misc{rfc4160, + author="K. Mimura and K. Yokoyama and T. Satoh and C. Kanaide and C. Allocchio", + title="{Internet Fax Gateway Requirements}", + howpublished="RFC 4160 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4160", + pages="1--13", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4160.txt", + key="RFC 4160", + abstract={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.}, + keywords="general switched telephone network facsimile service, gstn fax, internet fax service, i-fax, onramp gateway", + doi="10.17487/RFC4160", + } + +@misc{rfc4161, + author="K. Mimura and K. Yokoyama and T. Satoh and K. Watanabe and C. Kanaide", + title="{Guidelines for Optional Services for Internet Fax Gateways}", + howpublished="RFC 4161 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4161", + pages="1--12", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4161.txt", + key="RFC 4161", + abstract={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. 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. T his memo provides information for the Internet community.}, + keywords="general switched telephone network acsimile service, gstn fax, internet fax service, i-fax, offramp gateway, onramp gateway", + doi="10.17487/RFC4161", + } + +@misc{rfc4162, + author="H.J. Lee and J.H. Yoon and J.I. Lee", + title="{Addition of SEED Cipher Suites to Transport Layer Security (TLS)}", + howpublished="RFC 4162 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4162", + pages="1--6", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4162.txt", + key="RFC 4162", + abstract={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]}, + keywords="encryption algorithm, ciphersuite", + doi="10.17487/RFC4162", + } + +@misc{rfc4163, + author="L-E. Jonsson", + title="{RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression}", + howpublished="RFC 4163 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4163", + pages="1--9", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4163.txt", + key="RFC 4163", + abstract={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.}, + keywords="transmission control protocol, internet protocol, compression, performance considerations, intellectual property rights, ipr", + doi="10.17487/RFC4163", + } + +@misc{rfc4164, + author="G. Pelletier", + title="{RObust Header Compression (ROHC): Context Replication for ROHC Profiles}", + howpublished="RFC 4164 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4164", + pages="1--21", + year=2005, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4164.txt", + key="RFC 4164", + abstract={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]}, + keywords="context initialization, short-lived", + doi="10.17487/RFC4164", + } + +@misc{rfc4165, + author="T. George and B. Bidulock and R. Dantu and H. Schwarzbauer and K. Morneault", + title="{Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)}", + howpublished="RFC 4165 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4165", + pages="1--53", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4165.txt", + key="RFC 4165", + abstract={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]}, + keywords="ss7 over ip, ss7/ip, sigtran, m2ua", + doi="10.17487/RFC4165", + } + +@misc{rfc4166, + author="L. Coene and J. Pastor-Balbas", + title="{Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement}", + howpublished="RFC 4166 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4166", + pages="1--23", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4166.txt", + key="RFC 4166", + abstract={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.}, + doi="10.17487/RFC4166", + } + +@misc{rfc4167, + author="A. Lindem", + title="{Graceful OSPF Restart Implementation Report}", + howpublished="RFC 4167 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4167", + pages="1--6", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4167.txt", + key="RFC 4167", + abstract={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.}, + keywords="open shortest path first", + doi="10.17487/RFC4167", + } + +@misc{rfc4168, + author="J. Rosenberg and H. Schulzrinne and G. Camarillo", + title="{The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)}", + howpublished="RFC 4168 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4168", + pages="1--10", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4168.txt", + key="RFC 4168", + abstract={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]}, + keywords="transport mechanism", + doi="10.17487/RFC4168", + } + +@misc{rfc4169, + author="V. Torvinen and J. Arkko and M. Naslund", + title="{Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2}", + howpublished="RFC 4169 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4169", + pages="1--13", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4169.txt", + key="RFC 4169", + abstract={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.}, + keywords="tls, transport layer security, tunneled authentication, man-in-the-middle attacks", + doi="10.17487/RFC4169", + } + +@misc{rfc4170, + author="B. Thompson and T. Koren and D. Wing", + title="{Tunneling Multiplexed Compressed RTP (TCRTP)}", + howpublished="RFC 4170 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4170", + pages="1--24", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4170.txt", + key="RFC 4170", + abstract={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.}, + keywords="real-time transport protocol", + doi="10.17487/RFC4170", + } + +@misc{rfc4171, + author="J. Tseng and K. Gibbons and F. Travostino and C. Du Laney and J. Souza", + title="{Internet Storage Name Service (iSNS)}", + howpublished="RFC 4171 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4171", + pages="1--123", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4171.txt", + key="RFC 4171", + abstract={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]}, + keywords="isns servers, isns clients, fibre channel devices, ifcp, intelligent storage discovery", + doi="10.17487/RFC4171", + } + +@misc{rfc4172, + author="C. Monia and R. Mullendore and F. Travostino and W. Jeong and M. Edwards", + title="{iFCP - A Protocol for Internet Fibre Channel Storage Networking}", + howpublished="RFC 4172 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4172", + pages="1--111", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6172, 7146", +url="https://www.rfc-editor.org/rfc/rfc4172.txt", + key="RFC 4172", + abstract={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]}, + keywords="gateway-to-gateway, fibre channel fabric, tcp, transport control protocol", + doi="10.17487/RFC4172", + } + +@misc{rfc4173, + author="P. Sarkar and D. Missimer and C. Sapuntzakis", + title="{Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol}", + howpublished="RFC 4173 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4173", + pages="1--12", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc4173.txt", + key="RFC 4173", + abstract={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]}, + keywords="scsi, tcp, transport control protocol, boot server", + doi="10.17487/RFC4173", + } + +@misc{rfc4174, + author="C. Monia and J. Tseng and K. Gibbons", + title="{The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service}", + howpublished="RFC 4174 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4174", + pages="1--13", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc4174.txt", + key="RFC 4174", + abstract={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]}, + keywords="isns, internet storage name service, iscsi, internet scsi, ifcp, internet fibre channel, storage devices", + doi="10.17487/RFC4174", + } + +@misc{rfc4175, + author="L. Gharai and C. Perkins", + title="{RTP Payload Format for Uncompressed Video}", + howpublished="RFC 4175 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4175", + pages="1--18", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4421", +url="https://www.rfc-editor.org/rfc/rfc4175.txt", + key="RFC 4175", + abstract={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]}, + keywords="packetization scheme, real-time transport protocol, real time transport protocol, smpte, society of motion picture television engineers, video formats", + doi="10.17487/RFC4175", + } + +@misc{rfc4176, + author="Y. El {Mghazli (Ed.)} and T. Nadeau and M. Boucadair and K. Chan and A. Gonguet", + title="{Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management}", + howpublished="RFC 4176 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4176", + pages="1--21", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4176.txt", + key="RFC 4176", + abstract={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.}, + doi="10.17487/RFC4176", + } + +@misc{rfc4177, + author="G. Huston", + title="{Architectural Approaches to Multi-homing for IPv6}", + howpublished="RFC 4177 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4177", + pages="1--36", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4177.txt", + key="RFC 4177", + abstract={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.}, + keywords="internet protocol", + doi="10.17487/RFC4177", + } + +@misc{rfc4178, + author="L. Zhu and P. Leach and K. Jaganathan and W. Ingersoll", + title="{The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism}", + howpublished="RFC 4178 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4178", + pages="1--22", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4178.txt", + key="RFC 4178", + abstract={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. 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]}, + keywords="generic, service, application, security, program, interface", + doi="10.17487/RFC4178", + } + +@misc{rfc4179, + author="S. Kang", + title="{Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)}", + howpublished="RFC 4179 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4179", + pages="1--7", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4179.txt", + key="RFC 4179", + abstract={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.}, + keywords="nca, national computerization agency, digital resources", + doi="10.17487/RFC4179", + } + +@misc{rfc4180, + author="Y. Shafranovich", + title="{Common Format and MIME Type for Comma-Separated Values (CSV) Files}", + howpublished="RFC 4180 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4180", + pages="1--8", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7111", +url="https://www.rfc-editor.org/rfc/rfc4180.txt", + key="RFC 4180", + abstract={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.}, + keywords="text/csv", + doi="10.17487/RFC4180", + } + +@misc{rfc4181, + author="C. {Heard (Ed.)}", + title="{Guidelines for Authors and Reviewers of MIB Documents}", + howpublished="RFC 4181 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4181", + pages="1--42", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4841", +url="https://www.rfc-editor.org/rfc/rfc4181.txt", + key="RFC 4181", + abstract={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.}, + keywords="standards-track specifications, management information base, review", + doi="10.17487/RFC4181", + } + +@misc{rfc4182, + author="E. Rosen", + title="{Removing a Restriction on the use of MPLS Explicit NULL}", + howpublished="RFC 4182 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4182", + pages="1--7", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5462, 7274", +url="https://www.rfc-editor.org/rfc/rfc4182.txt", + key="RFC 4182", + abstract={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. This document updates RFC 3032. [STANDARDS-TRACK]}, + keywords="multiprotocol label switching, ipv4 explicit null", + doi="10.17487/RFC4182", + } + +@misc{rfc4183, + author="E. Warnicke", + title="{A Suggested Scheme for DNS Resolution of Networks and Gateways}", + howpublished="RFC 4183 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4183", + pages="1--9", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4183.txt", + key="RFC 4183", + abstract={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.}, + keywords="domain name space, ip address, internet protocol address, netmask, first-hop router, subnet", + doi="10.17487/RFC4183", + } + +@misc{rfc4184, + author="B. Link and T. Hager and J. Flaks", + title="{RTP Payload Format for AC-3 Audio}", + howpublished="RFC 4184 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4184", + pages="1--13", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4184.txt", + key="RFC 4184", + abstract={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]}, + keywords="real time transport protocol, audio compression", + doi="10.17487/RFC4184", + } + +@misc{rfc4185, + author="J. Klensin", + title="{National and Local Characters for DNS Top Level Domain (TLD) Names}", + howpublished="RFC 4185 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4185", + pages="1--19", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4185.txt", + key="RFC 4185", + abstract={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.}, + keywords="domain name system, multilingual, internationalized, local translation", + doi="10.17487/RFC4185", + } + +@misc{rfc4186, + author="H. {Haverinen (Ed.)} and J. {Salowey (Ed.)}", + title="{Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)}", + howpublished="RFC 4186 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4186", + pages="1--92", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4186.txt", + key="RFC 4186", + abstract={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.}, + keywords="3gpp", + doi="10.17487/RFC4186", + } + +@misc{rfc4187, + author="J. Arkko and H. Haverinen", + title="{Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)}", + howpublished="RFC 4187 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4187", + pages="1--79", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5448", +url="https://www.rfc-editor.org/rfc/rfc4187.txt", + key="RFC 4187", + abstract={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. 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.}, + keywords="3gpp, universal mobile telecommunications system, umts", + doi="10.17487/RFC4187", + } + +@misc{rfc4188, + author="K. {Norseth (Ed.)} and E. {Bell (Ed.)}", + title="{Definitions of Managed Objects for Bridges}", + howpublished="RFC 4188 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4188", + pages="1--44", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4188.txt", + key="RFC 4188", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-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. The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax. This memo obsoletes RFC 1493. [STANDARDS-TRACK]}, + keywords="BRIDGE-MIB, SNMP, MIB, standard, standards, management information base", + doi="10.17487/RFC4188", + } + +@misc{rfc4189, + author="K. Ono and S. Tachimoto", + title="{Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)}", + howpublished="RFC 4189 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4189", + pages="1--12", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4189.txt", + key="RFC 4189", + abstract={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.}, + keywords="user agent, ua, intermediaries", + doi="10.17487/RFC4189", + } + +@misc{rfc4190, + author="K. Carlberg and I. Brown and C. Beard", + title="{Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony}", + howpublished="RFC 4190 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4190", + pages="1--28", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4190.txt", + key="RFC 4190", + abstract={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.}, + keywords="disaster communications, prioritized voip", + doi="10.17487/RFC4190", + } + +@misc{rfc4191, + author="R. Draves and D. Thaler", + title="{Default Router Preferences and More-Specific Routes}", + howpublished="RFC 4191 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4191", + pages="1--15", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4191.txt", + key="RFC 4191", + abstract={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]}, + keywords="router advertisement", + doi="10.17487/RFC4191", + } + +@misc{rfc4192, + author="F. Baker and E. Lear and R. Droms", + title="{Procedures for Renumbering an IPv6 Network without a Flag Day}", + howpublished="RFC 4192 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4192", + pages="1--22", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4192.txt", + key="RFC 4192", + abstract={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.}, + keywords="prefix, internet protocol, network interface, make-before-break, enterprise, connecting routers", + doi="10.17487/RFC4192", + } + +@misc{rfc4193, + author="R. Hinden and B. Haberman", + title="{Unique Local IPv6 Unicast Addresses}", + howpublished="RFC 4193 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4193", + pages="1--16", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4193.txt", + key="RFC 4193", + abstract={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]}, + keywords="internet protocol, local communication", + doi="10.17487/RFC4193", + } + +@misc{rfc4194, + author="J. Strombergson and L. Walleij and P. Faltstrom", + title="{The S Hexdump Format}", + howpublished="RFC 4194 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4194", + pages="1--13", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4194.txt", + key="RFC 4194", + abstract={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]}, + keywords="shf, standard hex format, secure hash standard, shs, sha-1, nist fips 180-2, binary data, dump format, hexadecimal, intel hex format, s-rec, extensible markup language, xml", + doi="10.17487/RFC4194", + } + +@misc{rfc4195, + author="W. Kameyama", + title="{A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum}", + howpublished="RFC 4195 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4195", + pages="1--6", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4195.txt", + key="RFC 4195", + abstract={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.}, + keywords="digital broadcasting, tv, radio, storage systems, metadata, schemas", + doi="10.17487/RFC4195", + } + +@misc{rfc4196, + author="H.J. Lee and J.H. Yoon and S.L. Lee and J.I. Lee", + title="{The SEED Cipher Algorithm and Its Use with IPsec}", + howpublished="RFC 4196 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4196", + pages="1--12", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4196.txt", + key="RFC 4196", + abstract={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]}, + keywords="ipsec esp, encryption algorithm", + doi="10.17487/RFC4196", + } + +@misc{rfc4197, + author="M. {Riegel (Ed.)}", + title="{Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks}", + howpublished="RFC 4197 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4197", + pages="1--24", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4197.txt", + key="RFC 4197", + abstract={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.}, + keywords="digital signatures, plesiochronous digital hierarchy, sonet, synchronous optical network, sdh, synchronous digital hierarchy, pwe3, pseudo wire emulation", + doi="10.17487/RFC4197", + } + +@misc{rfc4198, + author="D. Tessman", + title="{A Uniform Resource Name (URN) Namespace for Federated Content}", + howpublished="RFC 4198 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4198", + pages="1--7", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4198.txt", + key="RFC 4198", + abstract={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.}, + keywords="content resource, content collections", + doi="10.17487/RFC4198", + } + +@misc{rfc4201, + author="K. Kompella and Y. Rekhter and L. Berger", + title="{Link Bundling in MPLS Traffic Engineering (TE)}", + howpublished="RFC 4201 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4201", + pages="1--12", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4201.txt", + key="RFC 4201", + abstract={For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> 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]}, + keywords="multiprotocol label switching, generalized multiprotocol label switching, gmpls, lsp, label switched path, interface identification tlvs", + doi="10.17487/RFC4201", + } + +@misc{rfc4202, + author="K. {Kompella (Ed.)} and Y. {Rekhter (Ed.)}", + title="{Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}", + howpublished="RFC 4202 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4202", + pages="1--27", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6001, 6002, 7074", +url="https://www.rfc-editor.org/rfc/rfc4202.txt", + key="RFC 4202", + abstract={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]}, + keywords="open shortest path first", + doi="10.17487/RFC4202", + } + +@misc{rfc4203, + author="K. {Kompella (Ed.)} and Y. {Rekhter (Ed.)}", + title="{OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}", + howpublished="RFC 4203 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4203", + pages="1--11", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6001, 6002, 7074", +url="https://www.rfc-editor.org/rfc/rfc4203.txt", + key="RFC 4203", + abstract={This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]}, + keywords="open shortest path first", + doi="10.17487/RFC4203", + } + +@misc{rfc4204, + author="J. {Lang (Ed.)}", + title="{Link Management Protocol (LMP)}", + howpublished="RFC 4204 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4204", + pages="1--86", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6898", +url="https://www.rfc-editor.org/rfc/rfc4204.txt", + key="RFC 4204", + abstract={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]}, + keywords="gmpls, sonet, sdh, discovery, link verification, fault managment, control channel management, link property correlation, traffic engineering links, trace monitoring", + doi="10.17487/RFC4204", + } + +@misc{rfc4205, + author="K. {Kompella (Ed.)} and Y. {Rekhter (Ed.)}", + title="{Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}", + howpublished="RFC 4205 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4205", + pages="1--11", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5307", +url="https://www.rfc-editor.org/rfc/rfc4205.txt", + key="RFC 4205", + abstract={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.}, + doi="10.17487/RFC4205", + } + +@misc{rfc4206, + author="K. Kompella and Y. Rekhter", + title="{Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)}", + howpublished="RFC 4206 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4206", + pages="1--14", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6001, 6107", +url="https://www.rfc-editor.org/rfc/rfc4206.txt", + key="RFC 4206", + abstract={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). This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]}, + keywords="lsr, label switching router, te lsp, fa, forwarding adjacency", + doi="10.17487/RFC4206", + } + +@misc{rfc4207, + author="J. Lang and D. Papadimitriou", + title="{Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages}", + howpublished="RFC 4207 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4207", + pages="1--15", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6898", +url="https://www.rfc-editor.org/rfc/rfc4207.txt", + key="RFC 4207", + abstract={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]}, + keywords="gmpls, discovery, link verification, fault management, control channel management, link property correlation, traffic engineering links, trace monitoring", + doi="10.17487/RFC4207", + } + +@misc{rfc4208, + author="G. Swallow and J. Drake and H. Ishimatsu and Y. Rekhter", + title="{Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model}", + howpublished="RFC 4208 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4208", + pages="1--13", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4208.txt", + key="RFC 4208", + abstract={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]}, + keywords="lsp, label switched paths, routing protocol, signaling protocol", + doi="10.17487/RFC4208", + } + +@misc{rfc4209, + author="A. {Fredette (Ed.)} and J. {Lang (Ed.)}", + title="{Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems}", + howpublished="RFC 4209 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4209", + pages="1--16", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6898", +url="https://www.rfc-editor.org/rfc/rfc4209.txt", + key="RFC 4209", + abstract={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]}, + keywords="te, traffic engineering, peer nodes, ols, optical link interface requirements", + doi="10.17487/RFC4209", + } + +@misc{rfc4210, + author="C. Adams and S. Farrell and T. Kause and T. Mononen", + title="{Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)}", + howpublished="RFC 4210 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4210", + pages="1--95", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6712", +url="https://www.rfc-editor.org/rfc/rfc4210.txt", + key="RFC 4210", + abstract={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]}, + keywords="PKICMP, cryptographic authentication, pkix, pki, X.509v3, certificate creation, certificate management, ca, certification authority", + doi="10.17487/RFC4210", + } + +@misc{rfc4211, + author="J. Schaad", + title="{Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)}", + howpublished="RFC 4211 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4211", + pages="1--40", + year=2005, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4211.txt", + key="RFC 4211", + abstract={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]}, + keywords="X.509-CRMF, certification authority, ca, registration authority, ra, pkix, pki, certificate production, crmf, security, encryption, authenticaion", + doi="10.17487/RFC4211", + } + +@misc{rfc4212, + author="M. Blinov and C. Adams", + title="{Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols}", + howpublished="RFC 4212 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4212", + pages="1--19", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4212.txt", + key="RFC 4212", + abstract={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.}, + keywords="X.509v3, public-key certificates, crmf, certificate request message format, pkix certificate management protocol, pkix-cmp, certificate management messages over cms, cmc", + doi="10.17487/RFC4212", + } + +@misc{rfc4213, + author="E. Nordmark and R. Gilligan", + title="{Basic Transition Mechanisms for IPv6 Hosts and Routers}", + howpublished="RFC 4213 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4213", + pages="1--27", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4213.txt", + key="RFC 4213", + abstract={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. This document obsoletes RFC 2893. [STANDARDS-TRACK]}, + keywords="TRANS-IPV6, ipv4, dual sack, configured tunneling", + doi="10.17487/RFC4213", + } + +@misc{rfc4214, + author="F. Templin and T. Gleeson and M. Talwar and D. Thaler", + title="{Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)}", + howpublished="RFC 4214 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4214", + pages="1--14", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5214", +url="https://www.rfc-editor.org/rfc/rfc4214.txt", + key="RFC 4214", + abstract={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.}, + keywords="ISATAP], ipv4, link layer, nbma, non-broadcast multiple access", + doi="10.17487/RFC4214", + } + +@misc{rfc4215, + author="J. {Wiljakka (Ed.)}", + title="{Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks}", + howpublished="RFC 4215 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4215", + pages="1--24", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4215.txt", + key="RFC 4215", + abstract={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. 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.}, + keywords="internet protocol, gprs, general packet radio service, global system for mobile communications, gsm, universal mobile telecommunications system, umts, wideband code division multiple access, wcdma", + doi="10.17487/RFC4215", + } + +@misc{rfc4216, + author="R. {Zhang (Ed.)} and J.-P. {Vasseur (Ed.)}", + title="{MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements}", + howpublished="RFC 4216 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4216", + pages="1--29", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4216.txt", + key="RFC 4216", + abstract={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.}, + keywords="inter-as, mpls-te", + doi="10.17487/RFC4216", + } + +@misc{rfc4217, + author="P. Ford-Hutchinson", + title="{Securing FTP with TLS}", + howpublished="RFC 4217 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4217", + pages="1--29", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4217.txt", + key="RFC 4217", + abstract={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.''. 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]}, + keywords="security, authentication, file transfer protocol, transport layer security", + doi="10.17487/RFC4217", + } + +@misc{rfc4218, + author="E. Nordmark and T. Li", + title="{Threats Relating to IPv6 Multihoming Solutions}", + howpublished="RFC 4218 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4218", + pages="1--31", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4218.txt", + key="RFC 4218", + abstract={This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. 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.}, + keywords="security threats, internet protocol version 6", + doi="10.17487/RFC4218", + } + +@misc{rfc4219, + author="E. Lear", + title="{Things Multihoming in IPv6 (MULTI6) Developers Should Think About}", + howpublished="RFC 4219 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4219", + pages="1--12", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4219.txt", + key="RFC 4219", + abstract={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.}, + keywords="security threats, internet protocol version 6", + doi="10.17487/RFC4219", + } + +@misc{rfc4220, + author="M. Dubuc and T. Nadeau and J. Lang", + title="{Traffic Engineering Link Management Information Base}", + howpublished="RFC 4220 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4220", + pages="1--54", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4220.txt", + key="RFC 4220", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]}, + keywords="mib, network management protocols, te, te-link-std-mib", + doi="10.17487/RFC4220", + } + +@misc{rfc4221, + author="T. Nadeau and C. Srinivasan and A. Farrel", + title="{Multiprotocol Label Switching (MPLS) Management Overview}", + howpublished="RFC 4221 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4221", + pages="1--32", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4221.txt", + key="RFC 4221", + abstract={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. 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.}, + keywords="mib, management information base, management architecture, network management", + doi="10.17487/RFC4221", + } + +@misc{rfc4222, + author="G. {Choudhury (Ed.)}", + title="{Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance}", + howpublished="RFC 4222 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4222", + pages="1--15", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4222.txt", + key="RFC 4222", + abstract={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.}, + keywords="open shortest path first, lsa, link state advertisement", + doi="10.17487/RFC4222", + } + +@misc{rfc4223, + author="P. Savola", + title="{Reclassification of RFC 1863 to Historic}", + howpublished="RFC 4223 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4223", + pages="1--3", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4223.txt", + key="RFC 4223", + abstract={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.}, + keywords="BGP-IDRP, border, gateway, protocol, inter-domain, routing", + doi="10.17487/RFC4223", + } + +@misc{rfc4224, + author="G. Pelletier and L-E. Jonsson and K. Sandlund", + title="{RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets}", + howpublished="RFC 4224 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4224", + pages="1--21", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4224.txt", + key="RFC 4224", + abstract={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.}, + doi="10.17487/RFC4224", + } + +@misc{rfc4225, + author="P. Nikander and J. Arkko and T. Aura and G. Montenegro and E. Nordmark", + title="{Mobile IP Version 6 Route Optimization Security Design Background}", + howpublished="RFC 4225 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4225", + pages="1--37", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4225.txt", + key="RFC 4225", + abstract={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. 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.}, + keywords="mipv6, mip", + doi="10.17487/RFC4225", + } + +@misc{rfc4226, + author="D. M'Raihi and M. Bellare and F. Hoornaert and D. Naccache and O. Ranen", + title="{HOTP: An HMAC-Based One-Time Password Algorithm}", + howpublished="RFC 4226 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4226", + pages="1--37", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4226.txt", + key="RFC 4226", + abstract={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. 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.}, + keywords="hashed message authentication code, security analysis, oath, open authentication, authentication, OATH", + doi="10.17487/RFC4226", + } + +@misc{rfc4227, + author="E. O'Tuathail and M. Rose", + title="{Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)}", + howpublished="RFC 4227 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4227", + pages="1--21", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4227.txt", + key="RFC 4227", + abstract={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. 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]}, + keywords="xml, extensible markup language, remote procedure calling, rpc, asynchronous event notification, unacknowledged messages, binding", + doi="10.17487/RFC4227", + } + +@misc{rfc4228, + author="A. Rousskov", + title="{Requirements for an IETF Draft Submission Toolset}", + howpublished="RFC 4228 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4228", + pages="1--31", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4228.txt", + key="RFC 4228", + abstract={This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community.}, + keywords="automation, tool", + doi="10.17487/RFC4228", + } + +@misc{rfc4229, + author="M. Nottingham and J. Mogul", + title="{HTTP Header Field Registrations}", + howpublished="RFC 4229 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4229", + pages="1--53", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4229.txt", + key="RFC 4229", + abstract={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.}, + keywords="hyper text transfer protocol", + doi="10.17487/RFC4229", + } + +@misc{rfc4230, + author="H. Tschofenig and R. Graveman", + title="{RSVP Security Properties}", + howpublished="RFC 4230 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4230", + pages="1--48", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4230.txt", + key="RFC 4230", + abstract={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.}, + keywords="resource reservation protocol", + doi="10.17487/RFC4230", + } + +@misc{rfc4231, + author="M. Nystrom", + title="{Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512}", + howpublished="RFC 4231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4231", + pages="1--9", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4231.txt", + key="RFC 4231", + abstract={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]}, + keywords="message authentication codes, message authentication schemes", + doi="10.17487/RFC4231", + } + +@misc{rfc4233, + author="K. Morneault and S. Rengasami and M. Kalla and G. Sidebottom", + title="{Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer}", + howpublished="RFC 4233 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4233", + pages="1--73", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5133", +url="https://www.rfc-editor.org/rfc/rfc4233.txt", + key="RFC 4233", + abstract={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. This document obsoletes RFC 3057. [STANDARDS-TRACK]}, + keywords="stream control transmission protocol, sctp, signaling gateway, sg, media gateway controller, mgc, signaling, media, gateway, interface", + doi="10.17487/RFC4233", + } + +@misc{rfc4234, + author="D. {Crocker (Ed.)} and P. Overell", + title="{Augmented BNF for Syntax Specifications: ABNF}", + howpublished="RFC 4234 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4234", + pages="1--16", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5234", +url="https://www.rfc-editor.org/rfc/rfc4234.txt", + key="RFC 4234", + abstract={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]}, + keywords="ABNF], backus-naur form, augmented backus-naur form, rule definitions, encoding, core lexical analyzer, electronic mail", + doi="10.17487/RFC4234", + } + +@misc{rfc4235, + author="J. Rosenberg and H. Schulzrinne and R. {Mahy (Ed.)}", + title="{An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)}", + howpublished="RFC 4235 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4235", + pages="1--39", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7463", +url="https://www.rfc-editor.org/rfc/rfc4235.txt", + key="RFC 4235", + abstract={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]}, + keywords="sip events, dialog package", + doi="10.17487/RFC4235", + } + +@misc{rfc4236, + author="A. Rousskov and M. Stecher", + title="{HTTP Adaptation with Open Pluggable Edge Services (OPES)}", + howpublished="RFC 4236 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4236", + pages="1--27", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4236.txt", + key="RFC 4236", + abstract={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]}, + keywords="callout protocol, ocp, opes tracing, opes bypass", + doi="10.17487/RFC4236", + } + +@misc{rfc4237, + author="G. Vaudreuil", + title="{Voice Messaging Directory Service}", + howpublished="RFC 4237 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4237", + pages="1--13", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4237.txt", + key="RFC 4237", + abstract={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. 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]}, + keywords="vpim, voice profile for internet mail", + doi="10.17487/RFC4237", + } + +@misc{rfc4238, + author="G. Vaudreuil", + title="{Voice Message Routing Service}", + howpublished="RFC 4238 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4238", + pages="1--10", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4238.txt", + key="RFC 4238", + abstract={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]}, + keywords="vpim, telephone number addressing, voice profile and intenret mail, vpim directory", + doi="10.17487/RFC4238", + } + +@misc{rfc4239, + author="S. McRae and G. Parsons", + title="{Internet Voice Messaging (IVM)}", + howpublished="RFC 4239 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4239", + pages="1--11", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4239.txt", + key="RFC 4239", + abstract={This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure. 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]}, + keywords="voicemail, vpim, voice profile for internet mail", + doi="10.17487/RFC4239", + } + +@misc{rfc4240, + author="E. {Burger (Ed.)} and J. Van Dyke and A. Spitzer", + title="{Basic Network Media Services with SIP}", + howpublished="RFC 4240 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4240", + pages="1--24", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4240.txt", + key="RFC 4240", + abstract={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. 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.}, + keywords="session initiation protocol, network media services, media servers, application servers", + doi="10.17487/RFC4240", + } + +@misc{rfc4241, + author="Y. Shirasaki and S. Miyakawa and T. Yamasaki and A. Takenouchi", + title="{A Model of IPv6/IPv4 Dual Stack Internet Access Service}", + howpublished="RFC 4241 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4241", + pages="1--10", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4241.txt", + key="RFC 4241", + abstract={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.}, + keywords="user network specification, ntt communications, adsl, cpe, customer preises equipment", + doi="10.17487/RFC4241", + } + +@misc{rfc4242, + author="S. Venaas and T. Chown and B. Volz", + title="{Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}", + howpublished="RFC 4242 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4242", + pages="1--8", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4242.txt", + key="RFC 4242", + abstract={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]}, + keywords="internet protocol", + doi="10.17487/RFC4242", + } + +@misc{rfc4243, + author="M. Stapp and R. Johnson and T. Palaniappan", + title="{Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option}", + howpublished="RFC 4243 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4243", + pages="1--7", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4243.txt", + key="RFC 4243", + abstract={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]}, + keywords="", + doi="10.17487/RFC4243", + } + +@misc{rfc4244, + author="M. {Barnes (Ed.)}", + title="{An Extension to the Session Initiation Protocol (SIP) for Request History Information}", + howpublished="RFC 4244 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4244", + pages="1--44", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7044", +url="https://www.rfc-editor.org/rfc/rfc4244.txt", + key="RFC 4244", + abstract={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]}, + keywords="history-info, retarget, enhanced services, voicemail, automatic call distribution", + doi="10.17487/RFC4244", + } + +@misc{rfc4245, + author="O. Levin and R. Even", + title="{High-Level Requirements for Tightly Coupled SIP Conferencing}", + howpublished="RFC 4245 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4245", + pages="1--12", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4245.txt", + key="RFC 4245", + abstract={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.}, + keywords="session initiation protocol", + doi="10.17487/RFC4245", + } + +@misc{rfc4246, + author="M. Dolan", + title="{International Standard Audiovisual Number (ISAN) URN Definition}", + howpublished="RFC 4246 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4246", + pages="1--6", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4246.txt", + key="RFC 4246", + abstract={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.}, + keywords="numbering system, international identification, audiovisual, uniform resource identifier", + doi="10.17487/RFC4246", + } + +@misc{rfc4247, + author="J. Ash and B. Goode and J. Hand and R. Zhang", + title="{Requirements for Header Compression over MPLS}", + howpublished="RFC 4247 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4247", + pages="1--11", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4247.txt", + key="RFC 4247", + abstract={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.}, + keywords="multiprotocol label switching, voip, voice over ip", + doi="10.17487/RFC4247", + } + +@misc{rfc4248, + author="P. Hoffman", + title="{The telnet URI Scheme}", + howpublished="RFC 4248 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4248", + pages="1--4", + year=2005, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4248.txt", + key="RFC 4248", + abstract={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]}, + keywords="uniform resource identifier, url, uniform resource locators", + doi="10.17487/RFC4248", + } + +@misc{rfc4249, + author="B. Lilly", + title="{Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components}", + howpublished="RFC 4249 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4249", + pages="1--14", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4249.txt", + key="RFC 4249", + abstract={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.}, + keywords="header field generator, header field parser", + doi="10.17487/RFC4249", + } + +@misc{rfc4250, + author="S. Lehtinen and C. {Lonvick (Ed.)}", + title="{The Secure Shell (SSH) Protocol Assigned Numbers}", + howpublished="RFC 4250 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4250", + pages="1--20", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8268", +url="https://www.rfc-editor.org/rfc/rfc4250.txt", + key="RFC 4250", + abstract={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]}, + keywords="remote login", + doi="10.17487/RFC4250", + } + +@misc{rfc4251, + author="T. Ylonen and C. {Lonvick (Ed.)}", + title="{The Secure Shell (SSH) Protocol Architecture}", + howpublished="RFC 4251 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4251", + pages="1--30", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8308", +url="https://www.rfc-editor.org/rfc/rfc4251.txt", + key="RFC 4251", + abstract={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]}, + keywords="remote login, ssh algorithm", + doi="10.17487/RFC4251", + } + +@misc{rfc4252, + author="T. Ylonen and C. {Lonvick (Ed.)}", + title="{The Secure Shell (SSH) Authentication Protocol}", + howpublished="RFC 4252 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4252", + pages="1--17", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 8308, 8332", +url="https://www.rfc-editor.org/rfc/rfc4252.txt", + key="RFC 4252", + abstract={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]}, + keywords="remote login, public key, password, host-based client authentication", + doi="10.17487/RFC4252", + } + +@misc{rfc4253, + author="T. Ylonen and C. {Lonvick (Ed.)}", + title="{The Secure Shell (SSH) Transport Layer Protocol}", + howpublished="RFC 4253 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4253", + pages="1--32", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6668, 8268, 8308, 8332", +url="https://www.rfc-editor.org/rfc/rfc4253.txt", + key="RFC 4253", + abstract={The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. 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. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. 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]}, + keywords="remote login, encryption, server authentication, integrity protection, diffie-hellman key exchange, diffie hellman", + doi="10.17487/RFC4253", + } + +@misc{rfc4254, + author="T. Ylonen and C. {Lonvick (Ed.)}", + title="{The Secure Shell (SSH) Connection Protocol}", + howpublished="RFC 4254 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4254", + pages="1--24", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8308", +url="https://www.rfc-editor.org/rfc/rfc4254.txt", + key="RFC 4254", + abstract={Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. 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. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK]}, + keywords="remote login, interactive login, remote execution, encrypted tunnel", + doi="10.17487/RFC4254", + } + +@misc{rfc4255, + author="J. Schlyter and W. Griffin", + title="{Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints}", + howpublished="RFC 4255 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4255", + pages="1--9", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4255.txt", + key="RFC 4255", + abstract={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]}, + keywords="domain name system, dnssec, domain name system security", + doi="10.17487/RFC4255", + } + +@misc{rfc4256, + author="F. Cusack and M. Forssen", + title="{Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)}", + howpublished="RFC 4256 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4256", + pages="1--12", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4256.txt", + key="RFC 4256", + abstract={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]}, + keywords="remote login, alphanumeric input", + doi="10.17487/RFC4256", + } + +@misc{rfc4257, + author="G. Bernstein and E. Mannie and V. Sharma and E. Gray", + title="{Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks}", + howpublished="RFC 4257 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4257", + pages="1--35", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4257.txt", + key="RFC 4257", + abstract={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 meth ods and multi-layer circuit establishment, are also discussed. This memo provides information for the Internet community.}, + keywords="mpls, optical switching, sdh, sonet", + doi="10.17487/RFC4257", + } + +@misc{rfc4258, + author="D. {Brungard (Ed.)}", + title="{Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)}", + howpublished="RFC 4258 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4258", + pages="1--22", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4258.txt", + key="RFC 4258", + abstract={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). 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.}, + keywords="control domain, hierarchy, multi-level, multi-layer, inter-domain, intra-domain, e-nni, i-nni, uni", + doi="10.17487/RFC4258", + } + +@misc{rfc4259, + author="M.-J. Montpetit and G. Fairhurst and H. Clausen and B. Collini-Nocker and H. Linder", + title="{A Framework for Transmission of IP Datagrams over MPEG-2 Networks}", + howpublished="RFC 4259 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4259", + pages="1--42", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4259.txt", + key="RFC 4259", + abstract={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. 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.}, + keywords="digital television, dvb, digital video broadcast, atsc, advanced television systems committee", + doi="10.17487/RFC4259", + } + +@misc{rfc4260, + author="P. McCann", + title="{Mobile IPv6 Fast Handovers for 802.11 Networks}", + howpublished="RFC 4260 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4260", + pages="1--15", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4260.txt", + key="RFC 4260", + abstract={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.}, + keywords="link layer", + doi="10.17487/RFC4260", + } + +@misc{rfc4261, + author="J. Walker and A. {Kulkarni (Ed.)}", + title="{Common Open Policy Service (COPS) Over Transport Layer Security (TLS)}", + howpublished="RFC 4261 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4261", + pages="1--14", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4261.txt", + key="RFC 4261", + abstract={This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet. This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]}, + keywords="client-accept message", + doi="10.17487/RFC4261", + } + +@misc{rfc4262, + author="S. Santesson", + title="{X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities}", + howpublished="RFC 4262 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4262", + pages="1--5", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4262.txt", + key="RFC 4262", + abstract={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]}, + keywords="cryptographic capabilities", + doi="10.17487/RFC4262", + } + +@misc{rfc4263, + author="B. Lilly", + title="{Media Subtype Registration for Media Type text/troff}", + howpublished="RFC 4263 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4263", + pages="1--16", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4263.txt", + key="RFC 4263", + abstract={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.}, + doi="10.17487/RFC4263", + } + +@misc{rfc4264, + author="T. Griffin and G. Huston", + title="{BGP Wedgies}", + howpublished="RFC 4264 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4264", + pages="1--10", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4264.txt", + key="RFC 4264", + abstract={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.}, + keywords="border gateway protocol", + doi="10.17487/RFC4264", + } + +@misc{rfc4265, + author="B. Schliesser and T. Nadeau", + title="{Definition of Textual Conventions for Virtual Private Network (VPN) Management}", + howpublished="RFC 4265 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4265", + pages="1--6", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4265.txt", + key="RFC 4265", + abstract={This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). [STANDARDS-TRACK]}, + keywords="tc", + doi="10.17487/RFC4265", + } + +@misc{rfc4266, + author="P. Hoffman", + title="{The gopher URI Scheme}", + howpublished="RFC 4266 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4266", + pages="1--6", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4266.txt", + key="RFC 4266", + abstract={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]}, + keywords="uniform resource identifier, url", + doi="10.17487/RFC4266", + } + +@misc{rfc4267, + author="M. Froumentin", + 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}", + howpublished="RFC 4267 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4267", + pages="1--9", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4267.txt", + key="RFC 4267", + abstract={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.}, + keywords="voice browser, voice extensible markup language, voicexml, speech synthesis markup language, ssml, speech recognition grammar specification, srgs, call control xml, ccxml, pronunciation lexicon specification, pls", + doi="10.17487/RFC4267", + } + +@misc{rfc4268, + author="S. Chisholm and D. Perkins", + title="{Entity State MIB}", + howpublished="RFC 4268 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4268", + pages="1--19", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4268.txt", + key="RFC 4268", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the Entity MIB to provide information about the state of physical entities. 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]}, + keywords="management information base, snmp, entity-state-tc-mib", + doi="10.17487/RFC4268", + } + +@misc{rfc4269, + author="H.J. Lee and S.J. Lee and J.H. Yoon and D.H. Cheon and J.I. Lee", + title="{The SEED Encryption Algorithm}", + howpublished="RFC 4269 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4269", + pages="1--16", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4269.txt", + key="RFC 4269", + abstract={This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This document obsoletes RFC 4009. This memo provides information for the Internet community.}, + keywords="encryption algorithm, seed cbc, seed oid", + doi="10.17487/RFC4269", + } + +@misc{rfc4270, + author="P. Hoffman and B. Schneier", + title="{Attacks on Cryptographic Hashes in Internet Protocols}", + howpublished="RFC 4270 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4270", + pages="1--12", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4270.txt", + key="RFC 4270", + abstract={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.}, + keywords="collision attacks, hash algorithms, ip, digital certificates", + doi="10.17487/RFC4270", + } + +@misc{rfc4271, + author="Y. {Rekhter (Ed.)} and T. {Li (Ed.)} and S. {Hares (Ed.)}", + title="{A Border Gateway Protocol 4 (BGP-4)}", + howpublished="RFC 4271 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4271", + pages="1--104", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6286, 6608, 6793, 7606, 7607, 7705, 8212", +url="https://www.rfc-editor.org/rfc/rfc4271.txt", + key="RFC 4271", + abstract={This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. 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. 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. This document obsoletes RFC 1771. [STANDARDS-TRACK]}, + keywords="BGP-4, routing", + doi="10.17487/RFC4271", + } + +@misc{rfc4272, + author="S. Murphy", + title="{BGP Security Vulnerabilities Analysis}", + howpublished="RFC 4272 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4272", + pages="1--22", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4272.txt", + key="RFC 4272", + abstract={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. 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.}, + keywords="border gateway protocol, attacks, risks, insider threat", + doi="10.17487/RFC4272", + } + +@misc{rfc4273, + author="J. {Haas (Ed.)} and S. {Hares (Ed.)}", + title="{Definitions of Managed Objects for BGP-4}", + howpublished="RFC 4273 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4273", + pages="1--32", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4273.txt", + key="RFC 4273", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. 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. 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. This document obsoletes RFC 1 269 and RFC 1657. [STANDARDS-TRACK]}, + keywords="BGP-4-MIB, management information base, mib, border gateway protocol", + doi="10.17487/RFC4273", + } + +@misc{rfc4274, + author="D. Meyer and K. Patel", + title="{BGP-4 Protocol Analysis}", + howpublished="RFC 4274 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4274", + pages="1--16", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4274.txt", + key="RFC 4274", + abstract={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). 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.}, + keywords="border gateway protocol", + doi="10.17487/RFC4274", + } + +@misc{rfc4275, + author="S. Hares and D. Hares", + title="{BGP-4 MIB Implementation Survey}", + howpublished="RFC 4275 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4275", + pages="1--37", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4275.txt", + key="RFC 4275", + abstract={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.}, + keywords="border gateway protocol, management information base", + doi="10.17487/RFC4275", + } + +@misc{rfc4276, + author="S. Hares and A. Retana", + title="{BGP-4 Implementation Report}", + howpublished="RFC 4276 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4276", + pages="1--97", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4276.txt", + key="RFC 4276", + abstract={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). 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.}, + keywords="border gateway protocol", + doi="10.17487/RFC4276", + } + +@misc{rfc4277, + author="D. McPherson and K. Patel", + title="{Experience with the BGP-4 Protocol}", + howpublished="RFC 4277 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4277", + pages="1--19", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4277.txt", + key="RFC 4277", + abstract={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). 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.}, + keywords="border gateway protocol", + doi="10.17487/RFC4277", + } + +@misc{rfc4278, + author="S. Bellovin and A. Zinin", + title="{Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification}", + howpublished="RFC 4278 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4278", + pages="1--7", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4278.txt", + key="RFC 4278", + abstract={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.}, + keywords="border gateway protocol", + doi="10.17487/RFC4278", + } + +@misc{rfc4279, + author="P. {Eronen (Ed.)} and H. {Tschofenig (Ed.)}", + title="{Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)}", + howpublished="RFC 4279 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4279", + pages="1--15", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4279.txt", + key="RFC 4279", + abstract={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]}, + keywords="psk, psks, symmetric keys, diffie-hellman", + doi="10.17487/RFC4279", + } + +@misc{rfc4280, + author="K. Chowdhury and P. Yegani and L. Madour", + title="{Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers}", + howpublished="RFC 4280 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4280", + pages="1--11", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4280.txt", + key="RFC 4280", + abstract={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]}, + keywords="bcmcs, 3g, third generation, cellular telephone, mobile node, mn", + doi="10.17487/RFC4280", + } + +@misc{rfc4281, + author="R. Gellens and D. Singer and P. Frojdh", + title="{The Codecs Parameter for ``Bucket'' Media Types}", + howpublished="RFC 4281 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4281", + pages="1--29", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6381", +url="https://www.rfc-editor.org/rfc/rfc4281.txt", + key="RFC 4281", + abstract={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. 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. 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]}, + keywords="codec, container, audio, video, 3gpp, 3gpp2", + doi="10.17487/RFC4281", + } + +@misc{rfc4282, + author="B. Aboba and M. Beadles and J. Arkko and P. Eronen", + title="{The Network Access Identifier}", + howpublished="RFC 4282 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4282", + pages="1--16", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7542", +url="https://www.rfc-editor.org/rfc/rfc4282.txt", + key="RFC 4282", + abstract={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]}, + keywords="NAI, nai, roaming, tunneling", + doi="10.17487/RFC4282", + } + +@misc{rfc4283, + author="A. Patel and K. Leung and M. Khalil and H. Akhtar and K. Chowdhury", + title="{Mobile Node Identifier Option for Mobile IPv6 (MIPv6)}", + howpublished="RFC 4283 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4283", + pages="1--8", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4283.txt", + key="RFC 4283", + abstract={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]}, + keywords="mobility header, mobile nodes, correspondent nodes, home agents", + doi="10.17487/RFC4283", + } + +@misc{rfc4284, + author="F. Adrangi and V. Lortz and F. Bari and P. Eronen", + title="{Identity Selection Hints for the Extensible Authentication Protocol (EAP)}", + howpublished="RFC 4284 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4284", + pages="1--14", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4284.txt", + key="RFC 4284", + abstract={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. 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.}, + keywords="nai, network access identifier", + doi="10.17487/RFC4284", + } + +@misc{rfc4285, + author="A. Patel and K. Leung and M. Khalil and H. Akhtar and K. Chowdhury", + title="{Authentication Protocol for Mobile IPv6}", + howpublished="RFC 4285 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4285", + pages="1--19", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4285.txt", + key="RFC 4285", + abstract={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.}, + keywords="ip security, ipsec, mip6, mobile node, home agent", + doi="10.17487/RFC4285", + } + +@misc{rfc4286, + author="B. Haberman and J. Martin", + title="{Multicast Router Discovery}", + howpublished="RFC 4286 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4286", + pages="1--18", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4286.txt", + key="RFC 4286", + abstract={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. 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]}, + keywords="igmp, internet group management protocol, mld, multicast listener discovery, mrd", + doi="10.17487/RFC4286", + } + +@misc{rfc4287, + author="M. {Nottingham (Ed.)} and R. {Sayre (Ed.)}", + title="{The Atom Syndication Format}", + howpublished="RFC 4287 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4287", + pages="1--43", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5988", +url="https://www.rfc-editor.org/rfc/rfc4287.txt", + key="RFC 4287", + abstract={This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]}, + keywords="xml-basd web content, metadata", + doi="10.17487/RFC4287", + } + +@misc{rfc4288, + author="N. Freed and J. Klensin", + title="{Media Type Specifications and Registration Procedures}", + howpublished="RFC 4288 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4288", + pages="1--24", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6838", +url="https://www.rfc-editor.org/rfc/rfc4288.txt", + key="RFC 4288", + abstract={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.}, + keywords="mime, multipurpose internet mail extensions, media types", + doi="10.17487/RFC4288", + } + +@misc{rfc4289, + author="N. Freed and J. Klensin", + title="{Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures}", + howpublished="RFC 4289 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4289", + pages="1--11", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4289.txt", + key="RFC 4289", + abstract={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.}, + keywords="media, types, external, body, access, content-transfer-encodings", + doi="10.17487/RFC4289", + } + +@misc{rfc4290, + author="J. Klensin", + title="{Suggested Practices for Registration of Internationalized Domain Names (IDN)}", + howpublished="RFC 4290 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4290", + pages="1--28", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4290.txt", + key="RFC 4290", + abstract={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.}, + keywords="chinese domain names, japanese domain names, korean domain names", + doi="10.17487/RFC4290", + } + +@misc{rfc4291, + author="R. Hinden and S. Deering", + title="{IP Version 6 Addressing Architecture}", + howpublished="RFC 4291 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4291", + pages="1--25", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5952, 6052, 7136, 7346, 7371, 8064", +url="https://www.rfc-editor.org/rfc/rfc4291.txt", + key="RFC 4291", + abstract={This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, ``IP Version 6 Addressing Architecture''. [STANDARDS-TRACK]}, + keywords="internet protocol version 6, unicast, anycast, multicast, node", + doi="10.17487/RFC4291", + } + +@misc{rfc4292, + author="B. Haberman", + title="{IP Forwarding Table MIB}", + howpublished="RFC 4292 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4292", + pages="1--34", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4292.txt", + key="RFC 4292", + abstract={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]}, + keywords="TABLE-MIB, Management, Information, Base, Internet, Protocol", + doi="10.17487/RFC4292", + } + +@misc{rfc4293, + author="S. {Routhier (Ed.)}", + title="{Management Information Base for the Internet Protocol (IP)}", + howpublished="RFC 4293 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4293", + pages="1--122", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4293.txt", + key="RFC 4293", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]}, + keywords="MIB-IP, IP, Simple, Network, Management, Protocol, MIB, ipv6, ICMPv6-MIB|, mib, internet, protocol, ip mib, ipv4 mib, ipv6 mib, icmp mib, icmpv6 mib", + doi="10.17487/RFC4293", + } + +@misc{rfc4294, + author="J. {Loughney (Ed.)}", + title="{IPv6 Node Requirements}", + howpublished="RFC 4294 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4294", + pages="1--20", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6434, updated by RFC 5095", +url="https://www.rfc-editor.org/rfc/rfc4294.txt", + key="RFC 4294", + abstract={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.}, + keywords="internet protocol version 6", + doi="10.17487/RFC4294", + } + +@misc{rfc4295, + author="G. Keeni and K. Koide and K. Nagami and S. Gundavelli", + title="{Mobile IPv6 Management Information Base}", + howpublished="RFC 4295 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4295", + pages="1--109", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4295.txt", + key="RFC 4295", + abstract={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]}, + keywords="mib, mipv6", + doi="10.17487/RFC4295", + } + +@misc{rfc4296, + author="S. Bailey and T. Talpey", + title="{The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols}", + howpublished="RFC 4296 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4296", + pages="1--22", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4296.txt", + key="RFC 4296", + abstract={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.}, + keywords="rddp, warp", + doi="10.17487/RFC4296", + } + +@misc{rfc4297, + author="A. Romanow and J. Mogul and T. Talpey and S. Bailey", + title="{Remote Direct Memory Access (RDMA) over IP Problem Statement}", + howpublished="RFC 4297 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4297", + pages="1--20", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4297.txt", + key="RFC 4297", + abstract={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. 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.}, + keywords="overhead, copy avoidance", + doi="10.17487/RFC4297", + } + +@misc{rfc4298, + author="J.-H. Chen and W. Lee and J. Thyssen", + title="{RTP Payload Format for BroadVoice Speech Codecs}", + howpublished="RFC 4298 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4298", + pages="1--14", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4298.txt", + key="RFC 4298", + abstract={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]}, + keywords="real time transport, narroband, wideband, bv16 broadvoice16, sdp, session description protocol", + doi="10.17487/RFC4298", + } + +@misc{rfc4301, + author="S. Kent and K. Seo", + title="{Security Architecture for the Internet Protocol}", + howpublished="RFC 4301 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4301", + pages="1--101", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6040, 7619", +url="https://www.rfc-editor.org/rfc/rfc4301.txt", + key="RFC 4301", + abstract={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]}, + keywords="IPSEC, ipsec, authentication, encapsulation, IP, IPv4, IPv6, IP-layer, ip authentication header, ip security, IPsec, confidentiality, authentication integrity, anti-replay, ah, esp, encapsulating security payload, ike, internet key exchange, ikev2, esn, extended sequence number", + doi="10.17487/RFC4301", + } + +@misc{rfc4302, + author="S. Kent", + title="{IP Authentication Header}", + howpublished="RFC 4302 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4302", + pages="1--34", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4302.txt", + key="RFC 4302", + abstract={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]}, + keywords="IP-AUTH, ipsec, Internet, Protocol, AH, security, IPv4, IPv6, ip security, confidentiality, authentication, integrity, anti-replay, ah, esp, encapsulating security payload, ike, internet key exchange, ikev2, esn, extended sequence number", + doi="10.17487/RFC4302", + } + +@misc{rfc4303, + author="S. Kent", + title="{IP Encapsulating Security Payload (ESP)}", + howpublished="RFC 4303 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4303", + pages="1--44", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4303.txt", + key="RFC 4303", + abstract={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]}, + keywords="ESP, ipsec, internet, protocol, encapsulating, security, ipv4, ipv6, ip security, confidentiality, authentication, integrity, anti-replay, ah, ip authentication header, ike, internet key exchange, ikev2, esn, extended sequence number", + doi="10.17487/RFC4303", + } + +@misc{rfc4304, + author="S. Kent", + title="{Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)}", + howpublished="RFC 4304 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4304", + pages="1--5", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4304.txt", + key="RFC 4304", + abstract={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]}, + keywords="ipsecurity, anti-replay, ah, ip authentication header, esp, encapsulating security payload, ike, internet key exchange, ikev2", + doi="10.17487/RFC4304", + } + +@misc{rfc4305, + author="D. {Eastlake 3rd}", + title="{Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)}", + howpublished="RFC 4305 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4305", + pages="1--9", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4835", +url="https://www.rfc-editor.org/rfc/rfc4305.txt", + key="RFC 4305", + abstract={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]}, + keywords="ESP, ipsec, authentication, mechanism, header, security, architecture, payload, internet, protocol, encapsulating, ipv4, ipv6", + doi="10.17487/RFC4305", + } + +@misc{rfc4306, + author="C. {Kaufman (Ed.)}", + title="{Internet Key Exchange (IKEv2) Protocol}", + howpublished="RFC 4306 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4306", + pages="1--99", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5996, updated by RFC 5282", +url="https://www.rfc-editor.org/rfc/rfc4306.txt", + key="RFC 4306", + abstract={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 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. 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]}, + keywords="ISAKMPSEC, ipsec, internet, protocol, security, association, key, management, ipsec, cryptography, authentication, IKE, oakley, isakmp", + doi="10.17487/RFC4306", + } + +@misc{rfc4307, + author="J. Schiller", + title="{Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)}", + howpublished="RFC 4307 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4307", + pages="1--6", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8247", +url="https://www.rfc-editor.org/rfc/rfc4307.txt", + key="RFC 4307", + abstract={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]}, + keywords="ipsec, ike, internet key exchange", + doi="10.17487/RFC4307", + } + +@misc{rfc4308, + author="P. Hoffman", + title="{Cryptographic Suites for IPsec}", + howpublished="RFC 4308 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4308", + pages="1--7", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4308.txt", + key="RFC 4308", + abstract={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]}, + keywords="ike, internet key exchange, ikev2, security algorithms, ikev1", + doi="10.17487/RFC4308", + } + +@misc{rfc4309, + author="R. Housley", + title="{Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)}", + howpublished="RFC 4309 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4309", + pages="1--13", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4309.txt", + key="RFC 4309", + abstract={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]}, + keywords="cbc-mac mode, initialization vector, iv, confidentiality, data origin authentication, connectionless integrity", + doi="10.17487/RFC4309", + } + +@misc{rfc4310, + author="S. Hollenbeck", + title="{Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 4310 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4310", + pages="1--22", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5910", +url="https://www.rfc-editor.org/rfc/rfc4310.txt", + key="RFC 4310", + abstract={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]}, + keywords="dnssec, domain name system security extensions", + doi="10.17487/RFC4310", + } + +@misc{rfc4311, + author="R. Hinden and D. Thaler", + title="{IPv6 Host-to-Router Load Sharing}", + howpublished="RFC 4311 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4311", + pages="1--5", + year=2005, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4311.txt", + key="RFC 4311", + abstract={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]}, + keywords="internet protocol version 6, conceptual sending algorithm", + doi="10.17487/RFC4311", + } + +@misc{rfc4312, + author="A. Kato and S. Moriai and M. Kanda", + title="{The Camellia Cipher Algorithm and Its Use With IPsec}", + howpublished="RFC 4312 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4312", + pages="1--8", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4312.txt", + key="RFC 4312", + abstract={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]}, + keywords="cipher block chaining mode, initialization vector, iv, esp, encapsulating security payload, ip security", + doi="10.17487/RFC4312", + } + +@misc{rfc4313, + author="D. Oran", + title="{Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources}", + howpublished="RFC 4313 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4313", + pages="1--20", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4313.txt", + key="RFC 4313", + abstract={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.}, + keywords="speech processing, audio streams, si, speaker identification, sv, speaker verification, tts, text to speech", + doi="10.17487/RFC4313", + } + +@misc{rfc4314, + author="A. Melnikov", + title="{IMAP4 Access Control List (ACL) Extension}", + howpublished="RFC 4314 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4314", + pages="1--27", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4314.txt", + key="RFC 4314", + abstract={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. 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]}, + keywords="IMAP4-ACL, Control, List, interet message access protocol", + doi="10.17487/RFC4314", + } + +@misc{rfc4315, + author="M. Crispin", + title="{Internet Message Access Protocol (IMAP) - UIDPLUS extension}", + howpublished="RFC 4315 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4315", + pages="1--8", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4315.txt", + key="RFC 4315", + abstract={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]}, + keywords="IMAP4UIDPL, internet, message, access, protocol, disconnected, operation", + doi="10.17487/RFC4315", + } + +@misc{rfc4316, + author="J. Reschke", + title="{Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties}", + howpublished="RFC 4316 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4316", + pages="1--11", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4316.txt", + key="RFC 4316", + abstract={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.}, + keywords="datatying, propfind", + doi="10.17487/RFC4316", + } + +@misc{rfc4317, + author="A. Johnston and R. Sparks", + title="{Session Description Protocol (SDP) Offer/Answer Examples}", + howpublished="RFC 4317 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4317", + pages="1--24", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4317.txt", + key="RFC 4317", + abstract={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.}, + doi="10.17487/RFC4317", + } + +@misc{rfc4318, + author="D. Levi and D. Harrington", + title="{Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol}", + howpublished="RFC 4318 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4318", + pages="1--14", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4318.txt", + key="RFC 4318", + abstract={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]}, + keywords="management information base, simple network management protocol, transparent bridging, rstp-mib", + doi="10.17487/RFC4318", + } + +@misc{rfc4319, + author="C. Sikes and B. Ray and R. Abbi", + title="{Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines}", + howpublished="RFC 4319 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4319", + pages="1--75", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4319.txt", + key="RFC 4319", + abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing 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]}, + keywords="mib, management information base, hdsl2-shdsl-line-mib, interfaces", + doi="10.17487/RFC4319", + } + +@misc{rfc4320, + author="R. Sparks", + title="{Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction}", + howpublished="RFC 4320 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4320", + pages="1--7", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4320.txt", + key="RFC 4320", + abstract={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]}, + keywords="", + doi="10.17487/RFC4320", + } + +@misc{rfc4321, + author="R. Sparks", + title="{Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction}", + howpublished="RFC 4321 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4321", + pages="1--10", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4321.txt", + key="RFC 4321", + abstract={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.}, + doi="10.17487/RFC4321", + } + +@misc{rfc4322, + author="M. Richardson and D.H. Redelmeier", + title="{Opportunistic Encryption using the Internet Key Exchange (IKE)}", + howpublished="RFC 4322 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4322", + pages="1--44", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4322.txt", + key="RFC 4322", + abstract={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. 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.}, + keywords="oe, linux frees/wan, ipsec, dns, domain name space, dns security", + doi="10.17487/RFC4322", + } + +@misc{rfc4323, + author="M. Patrick and W. Murwin", + title="{Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)}", + howpublished="RFC 4323 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4323", + pages="1--89", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4323.txt", + key="RFC 4323", + abstract={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]}, + keywords="snmp, simple network management protocol, cm, cable modem, cmts, cable modem termination system, docs-ietf-qos-mib", + doi="10.17487/RFC4323", + } + +@misc{rfc4324, + author="D. Royer and G. Babics and S. Mansour", + title="{Calendar Access Protocol (CAP)}", + howpublished="RFC 4324 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4324", + pages="1--131", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4324.txt", + key="RFC 4324", + abstract={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.}, + keywords="calendar user, cu, calendar user agent, cua, ical, calender store, cs", + doi="10.17487/RFC4324", + } + +@misc{rfc4325, + author="S. Santesson and R. Housley", + title="{Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension}", + howpublished="RFC 4325 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4325", + pages="1--7", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5280", +url="https://www.rfc-editor.org/rfc/rfc4325.txt", + key="RFC 4325", + abstract={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]}, + keywords="issuer certificate", + doi="10.17487/RFC4325", + } + +@misc{rfc4326, + author="G. Fairhurst and B. Collini-Nocker", + title="{Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)}", + howpublished="RFC 4326 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4326", + pages="1--42", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7280", +url="https://www.rfc-editor.org/rfc/rfc4326.txt", + key="RFC 4326", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC4326", + } + +@misc{rfc4327, + author="M. Dubuc and T. Nadeau and J. Lang and E. McGinnis", + title="{Link Management Protocol (LMP) Management Information Base (MIB)}", + howpublished="RFC 4327 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4327", + pages="1--82", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4631", +url="https://www.rfc-editor.org/rfc/rfc4327.txt", + key="RFC 4327", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]}, + keywords="lmp-mib", + doi="10.17487/RFC4327", + } + +@misc{rfc4328, + author="D. {Papadimitriou (Ed.)}", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control}", + howpublished="RFC 4328 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4328", + pages="1--23", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7139", +url="https://www.rfc-editor.org/rfc/rfc4328.txt", + key="RFC 4328", + abstract={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]}, + keywords="otn, optical transport networks, pre-otn", + doi="10.17487/RFC4328", + } + +@misc{rfc4329, + author="B. Hoehrmann", + title="{Scripting Media Types}", + howpublished="RFC 4329 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4329", + pages="1--15", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4329.txt", + key="RFC 4329", + abstract={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.}, + keywords="JavaScript, EMACScript, mime, script, subtype", + doi="10.17487/RFC4329", + } + +@misc{rfc4330, + author="D. Mills", + title="{Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI}", + howpublished="RFC 4330 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4330", + pages="1--27", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5905", +url="https://www.rfc-editor.org/rfc/rfc4330.txt", + key="RFC 4330", + abstract={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. 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 u sed 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.}, + keywords="NTP, time, computer, clock, synchronization", + doi="10.17487/RFC4330", + } + +@misc{rfc4331, + author="B. Korver and L. Dusseault", + title="{Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections}", + howpublished="RFC 4331 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4331", + pages="1--10", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4331.txt", + key="RFC 4331", + abstract={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]}, + keywords="webdav", + doi="10.17487/RFC4331", + } + +@misc{rfc4332, + author="K. Leung and A. Patel and G. Tsirtsis and E. Klovning", + title="{Cisco's Mobile IPv4 Host Configuration Extensions}", + howpublished="RFC 4332 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4332", + pages="1--11", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4332.txt", + key="RFC 4332", + abstract={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.}, + keywords="dynamic host configuration protocol, dhcp, point-to-point, ip control protocol, ppp, ipcp", + doi="10.17487/RFC4332", + } + +@misc{rfc4333, + author="G. {Huston (Ed.)} and B. {Wijnen (Ed.)}", + title="{The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process}", + howpublished="RFC 4333 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4333", + pages="1--9", + year=2005, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4333.txt", + key="RFC 4333", + abstract={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.}, + keywords="iad, iasa, ietf administrative support activity, ietf administrative director", + doi="10.17487/RFC4333", + } + +@misc{rfc4334, + author="R. Housley and T. Moore", + title="{Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)}", + howpublished="RFC 4334 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4334", + pages="1--11", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4334.txt", + key="RFC 4334", + abstract={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]}, + keywords="eap, extensible authentication protocol, wireless lan, wlan, system service identifier, ssid", + doi="10.17487/RFC4334", + } + +@misc{rfc4335, + author="J. Galbraith and P. Remaker", + title="{The Secure Shell (SSH) Session Channel Break Extension}", + howpublished="RFC 4335 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4335", + pages="1--6", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4335.txt", + key="RFC 4335", + abstract={The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4335", + } + +@misc{rfc4336, + author="S. Floyd and M. Handley and E. Kohler", + title="{Problem Statement for the Datagram Congestion Control Protocol (DCCP)}", + howpublished="RFC 4336 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4336", + pages="1--22", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4336.txt", + key="RFC 4336", + abstract={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.}, + doi="10.17487/RFC4336", + } + +@misc{rfc4337, + author="Y Lim and D. Singer", + title="{MIME Type Registration for MPEG-4}", + howpublished="RFC 4337 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4337", + pages="1--11", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6381", +url="https://www.rfc-editor.org/rfc/rfc4337.txt", + key="RFC 4337", + abstract={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]}, + keywords="", + doi="10.17487/RFC4337", + } + +@misc{rfc4338, + author="C. DeSanti and C. Carlson and R. Nixon", + title="{Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel}", + howpublished="RFC 4338 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4338", + pages="1--33", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5494, 8064", +url="https://www.rfc-editor.org/rfc/rfc4338.txt", + key="RFC 4338", + abstract={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. This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]}, + keywords="link local address, link-local address", + doi="10.17487/RFC4338", + } + +@misc{rfc4339, + author="J. {Jeong (Ed.)}", + title="{IPv6 Host Configuration of DNS Server Information Approaches}", + howpublished="RFC 4339 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4339", + pages="1--26", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4339.txt", + key="RFC 4339", + abstract={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.}, + keywords="domain name server, internet protocol, address configuration, dhcpv6, dynamic host configuration protocol", + doi="10.17487/RFC4339", + } + +@misc{rfc4340, + author="E. Kohler and M. Handley and S. Floyd", + title="{Datagram Congestion Control Protocol (DCCP)}", + howpublished="RFC 4340 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4340", + pages="1--129", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5595, 5596, 6335, 6773", +url="https://www.rfc-editor.org/rfc/rfc4340.txt", + key="RFC 4340", + abstract={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]}, + keywords="transport protocol", + doi="10.17487/RFC4340", + } + +@misc{rfc4341, + author="S. Floyd and E. Kohler", + title="{Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control}", + howpublished="RFC 4341 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4341", + pages="1--20", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8311", +url="https://www.rfc-editor.org/rfc/rfc4341.txt", + key="RFC 4341", + abstract={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]}, + keywords="transport protocol, amid, additive increase multiplicative decrease", + doi="10.17487/RFC4341", + } + +@misc{rfc4342, + author="S. Floyd and E. Kohler and J. Padhye", + title="{Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)}", + howpublished="RFC 4342 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4342", + pages="1--33", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5348, 6323, 8311", +url="https://www.rfc-editor.org/rfc/rfc4342.txt", + key="RFC 4342", + abstract={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]}, + keywords="transport protocol, ecn, explicit congestion notification, ccid3", + doi="10.17487/RFC4342", + } + +@misc{rfc4343, + author="D. {Eastlake 3rd}", + title="{Domain Name System (DNS) Case Insensitivity Clarification}", + howpublished="RFC 4343 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4343", + pages="1--10", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4343.txt", + key="RFC 4343", + abstract={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]}, + keywords="", + doi="10.17487/RFC4343", + } + +@misc{rfc4344, + author="M. Bellare and T. Kohno and C. Namprempre", + title="{The Secure Shell (SSH) Transport Layer Encryption Modes}", + howpublished="RFC 4344 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4344", + pages="1--12", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4344.txt", + key="RFC 4344", + abstract={Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. 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]}, + keywords="rekey", + doi="10.17487/RFC4344", + } + +@misc{rfc4345, + author="B. Harris", + title="{Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol}", + howpublished="RFC 4345 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4345", + pages="1--5", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4345.txt", + key="RFC 4345", + abstract={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]}, + keywords="arcfour cipher, key scheduling algorithm", + doi="10.17487/RFC4345", + } + +@misc{rfc4346, + author="T. Dierks and E. Rescorla", + title="{The Transport Layer Security (TLS) Protocol Version 1.1}", + howpublished="RFC 4346 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4346", + pages="1--87", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5246, updated by RFCs 4366, 4680, 4681, 5746, 6176, 7465, 7507, 7919", +url="https://www.rfc-editor.org/rfc/rfc4346.txt", + key="RFC 4346", + abstract={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. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4346", + } + +@misc{rfc4347, + author="E. Rescorla and N. Modadugu", + title="{Datagram Transport Layer Security}", + howpublished="RFC 4347 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4347", + pages="1--25", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6347, updated by RFCs 5746, 7507", +url="https://www.rfc-editor.org/rfc/rfc4347.txt", + key="RFC 4347", + abstract={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. [STANDARDS-TRACK]}, + keywords="dtls", + doi="10.17487/RFC4347", + } + +@misc{rfc4348, + author="S. Ahmadi", + title="{Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec}", + howpublished="RFC 4348 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4348", + pages="1--32", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4424", +url="https://www.rfc-editor.org/rfc/rfc4348.txt", + key="RFC 4348", + abstract={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. 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]}, + keywords="speech codec, variable-rate multicode wideband speech codec", + doi="10.17487/RFC4348", + } + +@misc{rfc4349, + author="C. Pignataro and M. Townsley", + title="{High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)}", + howpublished="RFC 4349 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4349", + pages="1--11", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5641", +url="https://www.rfc-editor.org/rfc/rfc4349.txt", + key="RFC 4349", + abstract={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]}, + keywords="pseudowire", + doi="10.17487/RFC4349", + } + +@misc{rfc4350, + author="F. Hendrikx and C. Wallis", + title="{A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government}", + howpublished="RFC 4350 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4350", + pages="1--11", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4350.txt", + key="RFC 4350", + abstract={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.}, + keywords="nid, namespace identification", + doi="10.17487/RFC4350", + } + +@misc{rfc4351, + author="G. Hellstrom and P. Jones", + title="{Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream}", + howpublished="RFC 4351 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4351", + pages="1--20", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4351.txt", + key="RFC 4351", + abstract={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. One payload format is described for transmitting audio and text data within a single RTP session. 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.}, + keywords="itu-t recommendation t.140", + doi="10.17487/RFC4351", + } + +@misc{rfc4352, + author="J. Sjoberg and M. Westerlund and A. Lakaniemi and S. Wenger", + title="{RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec}", + howpublished="RFC 4352 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4352", + pages="1--38", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4352.txt", + key="RFC 4352", + abstract={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]}, + keywords="real-time transport protocol, audio signals", + doi="10.17487/RFC4352", + } + +@misc{rfc4353, + author="J. Rosenberg", + title="{A Framework for Conferencing with the Session Initiation Protocol (SIP)}", + howpublished="RFC 4353 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4353", + pages="1--29", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4353.txt", + key="RFC 4353", + abstract={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.}, + doi="10.17487/RFC4353", + } + +@misc{rfc4354, + author="M. Garcia-Martin", + 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}", + howpublished="RFC 4354 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4354", + pages="1--21", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4354.txt", + key="RFC 4354", + abstract={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.}, + keywords="oma, open mobile alliance", + doi="10.17487/RFC4354", + } + +@misc{rfc4355, + author="R. Brandner and L. Conroy and R. Stastny", + title="{IANA Registration for Enumservices email, fax, mms, ems, and sms}", + howpublished="RFC 4355 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4355", + pages="1--16", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4355.txt", + key="RFC 4355", + abstract={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]}, + keywords="domain name system", + doi="10.17487/RFC4355", + } + +@misc{rfc4356, + author="R. Gellens", + title="{Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail}", + howpublished="RFC 4356 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4356", + pages="1--31", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4356.txt", + key="RFC 4356", + abstract={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. 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. 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]}, + keywords="cellular telephone, x-mms", + doi="10.17487/RFC4356", + } + +@misc{rfc4357, + author="V. Popov and I. Kurepkin and S. Leontiev", + 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}", + howpublished="RFC 4357 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4357", + pages="1--51", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4357.txt", + key="RFC 4357", + abstract={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.}, + keywords="cpalgs, public-key, one-way, hash, block, cipher, encyption, decryption, mac, hmac, prf, wrap, unwrap, ukm, kek, key, parameter, derivation, digest, cbc, counter, mode, digital, signature", + doi="10.17487/RFC4357", + } + +@misc{rfc4358, + author="D. Smith", + title="{A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA)}", + howpublished="RFC 4358 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4358", + pages="1--6", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4358.txt", + key="RFC 4358", + abstract={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.}, + keywords="nid, namespace identifier, omna, open mobile naming authority", + doi="10.17487/RFC4358", + } + +@misc{rfc4359, + author="B. Weis", + title="{The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)}", + howpublished="RFC 4359 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4359", + pages="1--12", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4359.txt", + key="RFC 4359", + abstract={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]}, + keywords="ip encapsulating security payload, digital signature", + doi="10.17487/RFC4359", + } + +@misc{rfc4360, + author="S. Sangli and D. Tappan and Y. Rekhter", + title="{BGP Extended Communities Attribute}", + howpublished="RFC 4360 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4360", + pages="1--12", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7153, 7606", +url="https://www.rfc-editor.org/rfc/rfc4360.txt", + key="RFC 4360", + abstract={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]}, + keywords="", + doi="10.17487/RFC4360", + } + +@misc{rfc4361, + author="T. Lemon and B. Sommerfeld", + title="{Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)}", + howpublished="RFC 4361 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4361", + pages="1--12", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc4361.txt", + key="RFC 4361", + abstract={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]}, + keywords="dhcpv6", + doi="10.17487/RFC4361", + } + +@misc{rfc4362, + author="L-E. Jonsson and G. Pelletier and K. Sandlund", + title="{RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP}", + howpublished="RFC 4362 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4362", + pages="1--23", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4815", +url="https://www.rfc-editor.org/rfc/rfc4362.txt", + key="RFC 4362", + abstract={This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes. [STANDARDS-TRACK]}, + keywords="internet protocol, user datagram protocol, real-time transport protocol", + doi="10.17487/RFC4362", + } + +@misc{rfc4363, + author="D. Levi and D. Harrington", + title="{Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions}", + howpublished="RFC 4363 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4363", + pages="1--99", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4363.txt", + key="RFC 4363", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines 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). 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. This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]}, + keywords="mib, management information base, mac bridges, traffic classes, enhanced multicast filtering, p-bridge-mib, q-bridge-mib", + doi="10.17487/RFC4363", + } + +@misc{rfc4364, + author="E. Rosen and Y. Rekhter", + title="{BGP/MPLS IP Virtual Private Networks (VPNs)}", + howpublished="RFC 4364 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4364", + pages="1--47", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4577, 4684, 5462", +url="https://www.rfc-editor.org/rfc/rfc4364.txt", + key="RFC 4364", + abstract={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]}, + keywords="service provider, ip backbone, ce router, pe router, border, gateway, protocol, multiprotocol, label, switching, architecture, virtual, private, networks", + doi="10.17487/RFC4364", + } + +@misc{rfc4365, + author="E. Rosen", + title="{Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)}", + howpublished="RFC 4365 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4365", + pages="1--32", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4365.txt", + key="RFC 4365", + abstract={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.}, + doi="10.17487/RFC4365", + } + +@misc{rfc4366, + author="S. Blake-Wilson and M. Nystrom and D. Hopwood and J. Mikkelsen and T. Wright", + title="{Transport Layer Security (TLS) Extensions}", + howpublished="RFC 4366 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4366", + pages="1--30", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5246, 6066, updated by RFC 5746", +url="https://www.rfc-editor.org/rfc/rfc4366.txt", + key="RFC 4366", + abstract={This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]}, + keywords="transport, protocol, layer, authentication, privacy", + doi="10.17487/RFC4366", + } + +@misc{rfc4367, + author="J. {Rosenberg (Ed.)} and IAB", + title="{What's in a Name: False Assumptions about DNS Names}", + howpublished="RFC 4367 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4367", + pages="1--17", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4367.txt", + key="RFC 4367", + abstract={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 I nternet community.}, + keywords="domain name system", + doi="10.17487/RFC4367", + } + +@misc{rfc4368, + author="T. Nadeau and S. Hegde", + title="{Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition}", + howpublished="RFC 4368 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4368", + pages="1--22", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4368.txt", + key="RFC 4368", + abstract={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]}, + keywords="management information base, mpls-lc-atm-std-mib, mpls-lc-fr-std-mib", + doi="10.17487/RFC4368", + } + +@misc{rfc4369, + author="K. Gibbons and C. Monia and J. Tseng and F. Travostino", + title="{Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)}", + howpublished="RFC 4369 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4369", + pages="1--29", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6173", +url="https://www.rfc-editor.org/rfc/rfc4369.txt", + key="RFC 4369", + abstract={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]}, + keywords="mib, management information base, snmp, simple network management protocol, ifcp gateway, ifcp-mgmt-mib", + doi="10.17487/RFC4369", + } + +@misc{rfc4370, + author="R. Weltman", + title="{Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control}", + howpublished="RFC 4370 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4370", + pages="1--5", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4370.txt", + key="RFC 4370", + abstract={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]}, + keywords="proxy authorization control", + doi="10.17487/RFC4370", + } + +@misc{rfc4371, + author="B. {Carpenter (Ed.)} and L. {Lynch (Ed.)}", + title="{BCP 101 Update for IPR Trust}", + howpublished="RFC 4371 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4371", + pages="1--4", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4371.txt", + key="RFC 4371", + abstract={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.}, + keywords="", + doi="10.17487/RFC4371", + } + +@misc{rfc4372, + author="F. Adrangi and A. Lior and J. Korhonen and J. Loughney", + title="{Chargeable User Identity}", + howpublished="RFC 4372 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4372", + pages="1--10", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4372.txt", + key="RFC 4372", + abstract={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]}, + keywords="radius, remote authentication dial-in user service, roaming transaction, home network", + doi="10.17487/RFC4372", + } + +@misc{rfc4373, + author="R. Harrison and J. Sermersheim and Y. Dong", + title="{Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)}", + howpublished="RFC 4373 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4373", + pages="1--16", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4373.txt", + key="RFC 4373", + abstract={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. 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.}, + doi="10.17487/RFC4373", + } + +@misc{rfc4374, + author="G. McCobb", + title="{The application/xv+xml Media Type}", + howpublished="RFC 4374 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4374", + pages="1--6", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4374.txt", + key="RFC 4374", + abstract={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.}, + keywords="mime, sub-type, media descriptor, xhtml+voice", + doi="10.17487/RFC4374", + } + +@misc{rfc4375, + author="K. Carlberg", + title="{Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain}", + howpublished="RFC 4375 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4375", + pages="1--8", + year=2006, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4375.txt", + key="RFC 4375", + abstract={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.}, + keywords="resource, transit domain, stub domain", + doi="10.17487/RFC4375", + } + +@misc{rfc4376, + author="P. Koskelainen and J. Ott and H. Schulzrinne and X. Wu", + title="{Requirements for Floor Control Protocols}", + howpublished="RFC 4376 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4376", + pages="1--14", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4376.txt", + key="RFC 4376", + abstract={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.}, + keywords="shared resources, multiparty conferences", + doi="10.17487/RFC4376", + } + +@misc{rfc4377, + author="T. Nadeau and M. Morrow and G. Swallow and D. Allan and S. Matsushima", + title="{Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks}", + howpublished="RFC 4377 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4377", + pages="1--15", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4377.txt", + key="RFC 4377", + abstract={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.}, + doi="10.17487/RFC4377", + } + +@misc{rfc4378, + author="D. {Allan (Ed.)} and T. {Nadeau (Ed.)}", + title="{A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)}", + howpublished="RFC 4378 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4378", + pages="1--11", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4378.txt", + key="RFC 4378", + abstract={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.}, + keywords="data plane, fcaps", + doi="10.17487/RFC4378", + } + +@misc{rfc4379, + author="K. Kompella and G. Swallow", + title="{Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures}", + howpublished="RFC 4379 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4379", + pages="1--50", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8029, updated by RFCs 5462, 6424, 6425, 6426, 6829, 7506, 7537, 7743", +url="https://www.rfc-editor.org/rfc/rfc4379.txt", + key="RFC 4379", + abstract={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]}, + keywords="data plane", + doi="10.17487/RFC4379", + } + +@misc{rfc4380, + author="C. Huitema", + title="{Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)}", + howpublished="RFC 4380 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4380", + pages="1--53", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5991, 6081", +url="https://www.rfc-editor.org/rfc/rfc4380.txt", + key="RFC 4380", + abstract={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]}, + keywords="", + doi="10.17487/RFC4380", + } + +@misc{rfc4381, + author="M. Behringer", + title="{Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)}", + howpublished="RFC 4381 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4381", + pages="1--22", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4381.txt", + key="RFC 4381", + abstract={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. 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.}, + keywords="service provider, atm, asynchronous transfer mode, frame relay", + doi="10.17487/RFC4381", + } + +@misc{rfc4382, + author="T. {Nadeau (Ed.)} and H. van der {Linde (Ed.)}", + title="{MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base}", + howpublished="RFC 4382 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4382", + pages="1--44", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4382.txt", + key="RFC 4382", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects 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]}, + keywords="mib, management information base, multiprotocol label switching, label switching router, lsr, mpls-l3vpn-std-mib", + doi="10.17487/RFC4382", + } + +@misc{rfc4383, + author="M. Baugher and E. Carrara", + title="{The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)}", + howpublished="RFC 4383 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4383", + pages="1--19", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4383.txt", + key="RFC 4383", + abstract={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]}, + keywords="multicast data stream, broadcast data stream", + doi="10.17487/RFC4383", + } + +@misc{rfc4384, + author="D. Meyer", + title="{BGP Communities for Data Collection}", + howpublished="RFC 4384 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4384", + pages="1--12", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4384.txt", + key="RFC 4384", + abstract={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.}, + keywords="border gateway protocol", + doi="10.17487/RFC4384", + } + +@misc{rfc4385, + author="S. Bryant and G. Swallow and L. Martini and D. McPherson", + title="{Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN}", + howpublished="RFC 4385 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4385", + pages="1--12", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5586", +url="https://www.rfc-editor.org/rfc/rfc4385.txt", + key="RFC 4385", + abstract={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]}, + keywords="multiprotocol label switching, packet switched network, pseudowire associated channel header", + doi="10.17487/RFC4385", + } + +@misc{rfc4386, + author="S. Boeyen and P. Hallam-Baker", + title="{Internet X.509 Public Key Infrastructure Repository Locator Service}", + howpublished="RFC 4386 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4386", + pages="1--6", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4386.txt", + key="RFC 4386", + abstract={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.}, + keywords="pki, public key infrastructure, dns srv", + doi="10.17487/RFC4386", + } + +@misc{rfc4387, + author="P. {Gutmann (Ed.)}", + title="{Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP}", + howpublished="RFC 4387 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4387", + pages="1--25", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4387.txt", + key="RFC 4387", + abstract={The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the 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]}, + keywords="pki, hypertext transfer protocol", + doi="10.17487/RFC4387", + } + +@misc{rfc4388, + author="R. Woundy and K. Kinnear", + title="{Dynamic Host Configuration Protocol (DHCP) Leasequery}", + howpublished="RFC 4388 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4388", + pages="1--27", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6148", +url="https://www.rfc-editor.org/rfc/rfc4388.txt", + key="RFC 4388", + abstract={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]}, + keywords="dhcpv4, ip address", + doi="10.17487/RFC4388", + } + +@misc{rfc4389, + author="D. Thaler and M. Talwar and C. Patel", + title="{Neighbor Discovery Proxies (ND Proxy)}", + howpublished="RFC 4389 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4389", + pages="1--18", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4389.txt", + key="RFC 4389", + abstract={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.}, + keywords="ndproxy", + doi="10.17487/RFC4389", + } + +@misc{rfc4390, + author="V. Kashyap", + title="{Dynamic Host Configuration Protocol (DHCP) over InfiniBand}", + howpublished="RFC 4390 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4390", + pages="1--6", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4390.txt", + key="RFC 4390", + abstract={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]}, + keywords="bootstrap, boot, ipoib", + doi="10.17487/RFC4390", + } + +@misc{rfc4391, + author="J. Chu and V. Kashyap", + title="{Transmission of IP over InfiniBand (IPoIB)}", + howpublished="RFC 4391 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4391", + pages="1--21", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc4391.txt", + key="RFC 4391", + abstract={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]}, + keywords="address resolution protocol, arp, ib", + doi="10.17487/RFC4391", + } + +@misc{rfc4392, + author="V. Kashyap", + title="{IP over InfiniBand (IPoIB) Architecture}", + howpublished="RFC 4392 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4392", + pages="1--23", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4392.txt", + key="RFC 4392", + abstract={InfiniBand is a high-speed, channel-based interconnect between systems and devices. 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.}, + keywords="ib, ipv4, ipv6", + doi="10.17487/RFC4392", + } + +@misc{rfc4393, + author="H. Garudadri", + title="{MIME Type Registrations for 3GPP2 Multimedia Files}", + howpublished="RFC 4393 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4393", + pages="1--7", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6381", +url="https://www.rfc-editor.org/rfc/rfc4393.txt", + key="RFC 4393", + abstract={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]}, + keywords="third-generation partnership project 2", + doi="10.17487/RFC4393", + } + +@misc{rfc4394, + author="D. Fedyk and O. Aboul-Magd and D. Brungard and J. Lang and D. Papadimitriou", + title="{A Transport Network View of the Link Management Protocol (LMP)}", + howpublished="RFC 4394 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4394", + pages="1--18", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4394.txt", + key="RFC 4394", + abstract={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.}, + keywords="gmpls, ason, discovery, sdh, otn, sonet, pdh", + doi="10.17487/RFC4394", + } + +@misc{rfc4395, + author="T. Hansen and T. Hardie and L. Masinter", + title="{Guidelines and Registration Procedures for New URI Schemes}", + howpublished="RFC 4395 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4395", + pages="1--15", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7595", +url="https://www.rfc-editor.org/rfc/rfc4395.txt", + key="RFC 4395", + abstract={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.}, + keywords="uniform resource identifier, syntax, semantics", + doi="10.17487/RFC4395", + } + +@misc{rfc4396, + author="J. Rey and Y. Matsui", + title="{RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text}", + howpublished="RFC 4396 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4396", + pages="1--66", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4396.txt", + key="RFC 4396", + abstract={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]}, + keywords="3GPP, 3GPP timed text, streaming, real-time streaming, titling, decorated text, scrolling text, karaoke, hyperlinked text, highlighted text, blinking text, highlight color, text delay, text style, text box, text wrap, text sample, sample descriptions, modifier boxes, UTF-8, UTF-16", + doi="10.17487/RFC4396", + } + +@misc{rfc4397, + author="I. Bryskin and A. Farrel", + 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}", + howpublished="RFC 4397 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4397", + pages="1--19", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4397.txt", + key="RFC 4397", + abstract={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). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. 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.}, + doi="10.17487/RFC4397", + } + +@misc{rfc4398, + author="S. Josefsson", + title="{Storing Certificates in the Domain Name System (DNS)}", + howpublished="RFC 4398 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4398", + pages="1--17", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6944", +url="https://www.rfc-editor.org/rfc/rfc4398.txt", + key="RFC 4398", + abstract={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]}, + keywords="SC-DNS, cryptology, authenticity", + doi="10.17487/RFC4398", + } + +@misc{rfc4401, + author="N. Williams", + title="{A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)}", + howpublished="RFC 4401 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4401", + pages="1--8", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4401.txt", + key="RFC 4401", + abstract={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]}, + keywords="secure session layer, message integrity check, mic", + doi="10.17487/RFC4401", + } + +@misc{rfc4402, + author="N. Williams", + title="{A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism}", + howpublished="RFC 4402 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4402", + pages="1--5", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7802", +url="https://www.rfc-editor.org/rfc/rfc4402.txt", + key="RFC 4402", + abstract={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]}, + keywords="", + doi="10.17487/RFC4402", + } + +@misc{rfc4403, + author="B. Bergeson and K. Boogert and V. Nanjundaswamy", + title="{Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)}", + howpublished="RFC 4403 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4403", + pages="1--42", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4403.txt", + key="RFC 4403", + abstract={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.}, + keywords="LDAPv3", + doi="10.17487/RFC4403", + } + +@misc{rfc4404, + author="R. Natarajan and A. Rijhsinghani", + title="{Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP)}", + howpublished="RFC 4404 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4404", + pages="1--33", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4404.txt", + key="RFC 4404", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. [STANDARDS-TRACK]}, + keywords="mib, management information base, fcip-mgmt-mib", + doi="10.17487/RFC4404", + } + +@misc{rfc4405, + author="E. Allman and H. Katz", + title="{SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message}", + howpublished="RFC 4405 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4405", + pages="1--14", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4405.txt", + key="RFC 4405", + abstract={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.}, + keywords="spam, spoofing, phishing", + doi="10.17487/RFC4405", + } + +@misc{rfc4406, + author="J. Lyon and M. Wong", + title="{Sender ID: Authenticating E-Mail}", + howpublished="RFC 4406 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4406", + pages="1--19", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4406.txt", + key="RFC 4406", + abstract={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.}, + keywords="simple mail transfer protocol, spam, spoofing", + doi="10.17487/RFC4406", + } + +@misc{rfc4407, + author="J. Lyon", + title="{Purported Responsible Address in E-Mail Messages}", + howpublished="RFC 4407 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4407", + pages="1--7", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4407.txt", + key="RFC 4407", + abstract={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.}, + keywords="pra, purported responsible address", + doi="10.17487/RFC4407", + } + +@misc{rfc4408, + author="M. Wong and W. Schlitt", + title="{Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1}", + howpublished="RFC 4408 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4408", + pages="1--48", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7208, updated by RFC 6652", +url="https://www.rfc-editor.org/rfc/rfc4408.txt", + key="RFC 4408", + abstract={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.}, + keywords="spoofing, spf", + doi="10.17487/RFC4408", + } + +@misc{rfc4409, + author="R. Gellens and J. Klensin", + title="{Message Submission for Mail}", + howpublished="RFC 4409 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4409", + pages="1--17", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6409", +url="https://www.rfc-editor.org/rfc/rfc4409.txt", + key="RFC 4409", + abstract={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. Message relay and final delivery are unaffected, and continue to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]}, + keywords="smtp, simle mail transfer protocol, ua, user agent", + doi="10.17487/RFC4409", + } + +@misc{rfc4410, + author="M. Pullen and F. Zhao and D. Cohen", + title="{Selectively Reliable Multicast Protocol (SRMP)}", + howpublished="RFC 4410 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4410", + pages="1--30", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4410.txt", + key="RFC 4410", + abstract={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.}, + keywords="transport, best-effort, srt, selectively reliable transport", + doi="10.17487/RFC4410", + } + +@misc{rfc4411, + author="J. Polk", + title="{Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events}", + howpublished="RFC 4411 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4411", + pages="1--22", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4411.txt", + key="RFC 4411", + abstract={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]}, + keywords="Resource-Priority, preempt, preempted, Q.850, preconditions", + doi="10.17487/RFC4411", + } + +@misc{rfc4412, + author="H. Schulzrinne and J. Polk", + title="{Communications Resource Priority for the Session Initiation Protocol (SIP)}", + howpublished="RFC 4412 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4412", + pages="1--36", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7134", +url="https://www.rfc-editor.org/rfc/rfc4412.txt", + key="RFC 4412", + abstract={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]}, + keywords="RP, RPH, preferential, preempt, preempted, preemption, queue, DSN, DRSN, WPS, ETS, Q.735, Q735, disaster, I.255, flash, flash-override", + doi="10.17487/RFC4412", + } + +@misc{rfc4413, + author="M. West and S. McCann", + title="{TCP/IP Field Behavior}", + howpublished="RFC 4413 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4413", + pages="1--44", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4413.txt", + key="RFC 4413", + abstract={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.}, + keywords="transmission control protocol, header compression", + doi="10.17487/RFC4413", + } + +@misc{rfc4414, + author="A. Newton", + title="{An ENUM Registry Type for the Internet Registry Information Service (IRIS)}", + howpublished="RFC 4414 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4414", + pages="1--51", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4414.txt", + key="RFC 4414", + abstract={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]}, + keywords="", + doi="10.17487/RFC4414", + } + +@misc{rfc4415, + author="R. Brandner and L. Conroy and R. Stastny", + title="{IANA Registration for Enumservice Voice}", + howpublished="RFC 4415 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4415", + pages="1--8", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4415.txt", + key="RFC 4415", + abstract={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]}, + keywords="uniform resource identifier, uri, voice call, audio call", + doi="10.17487/RFC4415", + } + +@misc{rfc4416, + author="J. {Wong (Ed.)}", + title="{Goals for Internet Messaging to Support Diverse Service Environments}", + howpublished="RFC 4416 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4416", + pages="1--43", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4416.txt", + key="RFC 4416", + abstract={This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process. 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. 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. 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 environ ments. 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.}, + keywords="IMAP, protocol extensions, messaging, wireless, handheld, telephone user interface, multi-modal, LEMONADE, extension principles, history, background, motivation, cellular, interworking, constraints, TUI, WUI, client, MMS", + doi="10.17487/RFC4416", + } + +@misc{rfc4417, + author="P. {Resnick (Ed.)} and P. {Saint-Andre (Ed.)}", + title="{Report of the 2004 IAB Messaging Workshop}", + howpublished="RFC 4417 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4417", + pages="1--20", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4417.txt", + key="RFC 4417", + abstract={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.}, + keywords="internet architecture board, internet messaging", + doi="10.17487/RFC4417", + } + +@misc{rfc4418, + author="T. {Krovetz (Ed.)}", + title="{UMAC: Message Authentication Code using Universal Hashing}", + howpublished="RFC 4418 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4418", + pages="1--27", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4418.txt", + key="RFC 4418", + abstract={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. 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.}, + doi="10.17487/RFC4418", + } + +@misc{rfc4419, + author="M. Friedl and N. Provos and W. Simpson", + title="{Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol}", + howpublished="RFC 4419 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4419", + pages="1--10", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8270", +url="https://www.rfc-editor.org/rfc/rfc4419.txt", + key="RFC 4419", + abstract={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]}, + keywords="", + doi="10.17487/RFC4419", + } + +@misc{rfc4420, + author="A. {Farrel (Ed.)} and D. Papadimitriou and J.-P. Vasseur and A. Ayyangar", + title="{Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)}", + howpublished="RFC 4420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4420", + pages="1--21", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5420", +url="https://www.rfc-editor.org/rfc/rfc4420.txt", + key="RFC 4420", + abstract={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. 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. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LS Ps. [STANDARDS-TRACK]}, + keywords="SESSION\_ATTRIBUTE", + doi="10.17487/RFC4420", + } + +@misc{rfc4421, + author="C. Perkins", + title="{RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes}", + howpublished="RFC 4421 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4421", + pages="1--4", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4421.txt", + key="RFC 4421", + abstract={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]}, + keywords="realtime transport protocol, video stream", + doi="10.17487/RFC4421", + } + +@misc{rfc4422, + author="A. {Melnikov (Ed.)} and K. {Zeilenga (Ed.)}", + title="{Simple Authentication and Security Layer (SASL)}", + howpublished="RFC 4422 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4422", + pages="1--33", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4422.txt", + key="RFC 4422", + abstract={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. 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. This document obsoletes RFC 2222. [STANDARDS-TRACK]}, + keywords="SASL, encryption, protocol specific", + doi="10.17487/RFC4422", + } + +@misc{rfc4423, + author="R. Moskowitz and P. Nikander", + title="{Host Identity Protocol (HIP) Architecture}", + howpublished="RFC 4423 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4423", + pages="1--24", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4423.txt", + key="RFC 4423", + abstract={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.}, + doi="10.17487/RFC4423", + } + +@misc{rfc4424, + author="S. Ahmadi", + title="{Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec}", + howpublished="RFC 4424 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4424", + pages="1--8", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4424.txt", + key="RFC 4424", + abstract={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. 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]}, + keywords="speech codec, variable-rate multicode wideband speech codec", + doi="10.17487/RFC4424", + } + +@misc{rfc4425, + author="A. Klemets", + title="{RTP Payload Format for Video Codec 1 (VC-1)}", + howpublished="RFC 4425 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4425", + pages="1--36", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4425.txt", + key="RFC 4425", + abstract={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]}, + keywords="smpte 421m, wmv, wmv9, vc-9", + doi="10.17487/RFC4425", + } + +@misc{rfc4426, + author="J. {Lang (Ed.)} and B. {Rajagopalan (Ed.)} and D. {Papadimitriou (Ed.)}", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification}", + howpublished="RFC 4426 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4426", + pages="1--23", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4426.txt", + key="RFC 4426", + abstract={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]}, + keywords="", + doi="10.17487/RFC4426", + } + +@misc{rfc4427, + author="E. {Mannie (Ed.)} and D. {Papadimitriou (Ed.)}", + title="{Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)}", + howpublished="RFC 4427 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4427", + pages="1--22", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4427.txt", + key="RFC 4427", + abstract={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.}, + doi="10.17487/RFC4427", + } + +@misc{rfc4428, + author="D. {Papadimitriou (Ed.)} and E. {Mannie (Ed.)}", + title="{Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)}", + howpublished="RFC 4428 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4428", + pages="1--47", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4428.txt", + key="RFC 4428", + abstract={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.}, + doi="10.17487/RFC4428", + } + +@misc{rfc4429, + author="N. Moore", + title="{Optimistic Duplicate Address Detection (DAD) for IPv6}", + howpublished="RFC 4429 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4429", + pages="1--17", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7527", +url="https://www.rfc-editor.org/rfc/rfc4429.txt", + key="RFC 4429", + abstract={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]}, + keywords="internet protocol version 6, stateless address autoconfiguration, neighbor discovery", + doi="10.17487/RFC4429", + } + +@misc{rfc4430, + author="S. Sakane and K. Kamada and M. Thomas and J. Vilhuber", + title="{Kerberized Internet Negotiation of Keys (KINK)}", + howpublished="RFC 4430 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4430", + pages="1--40", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4430.txt", + key="RFC 4430", + abstract={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]}, + keywords="ike, internet key exchange", + doi="10.17487/RFC4430", + } + +@misc{rfc4431, + author="M. Andrews and S. Weiler", + title="{The DNSSEC Lookaside Validation (DLV) DNS Resource Record}", + howpublished="RFC 4431 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4431", + pages="1--4", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4431.txt", + key="RFC 4431", + abstract={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.}, + keywords="dns, domain name space", + doi="10.17487/RFC4431", + } + +@misc{rfc4432, + author="B. Harris", + title="{RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol}", + howpublished="RFC 4432 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4432", + pages="1--8", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4432.txt", + key="RFC 4432", + abstract={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]}, + keywords="rivest-sharmir-adleman, public key encryption", + doi="10.17487/RFC4432", + } + +@misc{rfc4433, + author="M. Kulkarni and A. Patel and K. Leung", + title="{Mobile IPv4 Dynamic Home Agent (HA) Assignment}", + howpublished="RFC 4433 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4433", + pages="1--25", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4433.txt", + key="RFC 4433", + abstract={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]}, + keywords="internet protocol, messaging", + doi="10.17487/RFC4433", + } + +@misc{rfc4434, + author="P. Hoffman", + title="{The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)}", + howpublished="RFC 4434 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4434", + pages="1--6", + year=2006, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4434.txt", + key="RFC 4434", + abstract={Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. [STANDARDS-TRACK]}, + keywords="security, ipsec, advanced encryption standard, mac, message authentication code", + doi="10.17487/RFC4434", + } + +@misc{rfc4435, + author="Y. Nomura and R. Walsh and J-P. Luoma and H. Asaeda and H. Schulzrinne", + title="{A Framework for the Usage of Internet Media Guides (IMGs)}", + howpublished="RFC 4435 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4435", + pages="1--22", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4435.txt", + key="RFC 4435", + abstract={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.}, + keywords="session description protocol, sdp, sdpng", + doi="10.17487/RFC4435", + } + +@misc{rfc4436, + author="B. Aboba and J. Carlson and S. Cheshire", + title="{Detecting Network Attachment in IPv4 (DNAv4)}", + howpublished="RFC 4436 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4436", + pages="1--15", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4436.txt", + key="RFC 4436", + abstract={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]}, + keywords="internet protocol", + doi="10.17487/RFC4436", + } + +@misc{rfc4437, + author="J. Whitehead and G. Clemm and J. {Reschke (Ed.)}", + title="{Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources}", + howpublished="RFC 4437 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4437", + pages="1--25", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4437.txt", + key="RFC 4437", + abstract={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.}, + keywords="http, hyper text transfer protocol", + doi="10.17487/RFC4437", + } + +@misc{rfc4438, + author="C. DeSanti and V. Gaonkar and H.K. Vivek and K. McCloghrie and S. Gai", + title="{Fibre-Channel Name Server MIB}", + howpublished="RFC 4438 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4438", + pages="1--36", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4438.txt", + key="RFC 4438", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the 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]}, + keywords="management information base, T11-fc-name-server-mib", + doi="10.17487/RFC4438", + } + +@misc{rfc4439, + author="C. DeSanti and V. Gaonkar and K. McCloghrie and S. Gai", + title="{Fibre Channel Fabric Address Manager MIB}", + howpublished="RFC 4439 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4439", + pages="1--40", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4439.txt", + key="RFC 4439", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. [STANDARDS-TRACK]}, + keywords="management information base, t11-tc-mib, t11-fc-fabric-addr-mgr-mib", + doi="10.17487/RFC4439", + } + +@misc{rfc4440, + author="S. {Floyd (Ed.)} and V. {Paxson (Ed.)} and A. {Falk (Ed.)} and IAB", + title="{IAB Thoughts on the Role of the Internet Research Task Force (IRTF)}", + howpublished="RFC 4440 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4440", + pages="1--13", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4440.txt", + key="RFC 4440", + abstract={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.}, + keywords="internet architecture board", + doi="10.17487/RFC4440", + } + +@misc{rfc4441, + author="B. {Aboba (Ed.)}", + title="{The IEEE 802/IETF Relationship}", + howpublished="RFC 4441 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4441", + pages="1--22", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7241", +url="https://www.rfc-editor.org/rfc/rfc4441.txt", + key="RFC 4441", + abstract={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.}, + keywords="snmp, aaa, simple network management protocol, authentication, authorization, accounting", + doi="10.17487/RFC4441", + } + +@misc{rfc4442, + author="S. Fries and H. Tschofenig", + title="{Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)}", + howpublished="RFC 4442 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4442", + pages="1--18", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4442.txt", + key="RFC 4442", + abstract={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. 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]}, + keywords="authentication, mikey, multimedia internet keying protocol", + doi="10.17487/RFC4442", + } + +@misc{rfc4443, + author="A. Conta and S. Deering and M. {Gupta (Ed.)}", + title="{Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification}", + howpublished="RFC 4443 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="4443", + pages="1--24", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 4884", +url="https://www.rfc-editor.org/rfc/rfc4443.txt", + key="RFC 4443", + abstract={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]}, + doi="10.17487/RFC4443", + } + +@misc{rfc4444, + author="J. {Parker (Ed.)}", + title="{Management Information Base for Intermediate System to Intermediate System (IS-IS)}", + howpublished="RFC 4444 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4444", + pages="1--103", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4444.txt", + key="RFC 4444", + abstract={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]}, + keywords="mib, routing protocol, isis-mib", + doi="10.17487/RFC4444", + } + +@misc{rfc4445, + author="J. Welch and J. Clark", + title="{A Proposed Media Delivery Index (MDI)}", + howpublished="RFC 4445 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4445", + pages="1--10", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4445.txt", + key="RFC 4445", + abstract={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.}, + doi="10.17487/RFC4445", + } + +@misc{rfc4446, + author="L. Martini", + title="{IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)}", + howpublished="RFC 4446 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4446", + pages="1--9", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4446.txt", + key="RFC 4446", + abstract={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.}, + keywords="", + doi="10.17487/RFC4446", + } + +@misc{rfc4447, + author="L. {Martini (Ed.)} and E. Rosen and N. El-Aawar and T. Smith and G. Heron", + title="{Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)}", + howpublished="RFC 4447 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4447", + pages="1--33", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8077, updated by RFCs 6723, 6870, 7358", +url="https://www.rfc-editor.org/rfc/rfc4447.txt", + key="RFC 4447", + abstract={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]}, + keywords="mpls, multiprotocol label switching protocol, pdu, protocol data units", + doi="10.17487/RFC4447", + } + +@misc{rfc4448, + author="L. {Martini (Ed.)} and E. Rosen and N. El-Aawar and G. Heron", + title="{Encapsulation Methods for Transport of Ethernet over MPLS Networks}", + howpublished="RFC 4448 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4448", + pages="1--24", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc4448.txt", + key="RFC 4448", + abstract={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]}, + keywords="pw, pseudowire, pdu, protocol data units", + doi="10.17487/RFC4448", + } + +@misc{rfc4449, + author="C. Perkins", + title="{Securing Mobile IPv6 Route Optimization Using a Static Shared Key}", + howpublished="RFC 4449 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4449", + pages="1--7", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4449.txt", + key="RFC 4449", + abstract={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]}, + keywords="mobile node, correspondent node, binding management key, binding updates", + doi="10.17487/RFC4449", + } + +@misc{rfc4450, + author="E. Lear and H. Alvestrand", + title="{Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents}", + howpublished="RFC 4450 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4450", + pages="1--11", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4450.txt", + key="RFC 4450", + abstract={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.}, + doi="10.17487/RFC4450", + } + +@misc{rfc4451, + author="D. McPherson and V. Gill", + title="{BGP MULTI\_EXIT\_DISC (MED) Considerations}", + howpublished="RFC 4451 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4451", + pages="1--13", + year=2006, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4451.txt", + key="RFC 4451", + abstract={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. 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.}, + keywords="border gateway protocol", + doi="10.17487/RFC4451", + } + +@misc{rfc4452, + author="H. Van de Sompel and T. Hammond and E. Neylon and S. Weibel", + title="{The ``info'' URI Scheme for Information Assets with Identifiers in Public Namespaces}", + howpublished="RFC 4452 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4452", + pages="1--17", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4452.txt", + key="RFC 4452", + abstract={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.}, + keywords="uniform resource identifier", + doi="10.17487/RFC4452", + } + +@misc{rfc4453, + author="J. Rosenberg and G. {Camarillo (Ed.)} and D. Willis", + title="{Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)}", + howpublished="RFC 4453 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4453", + pages="1--8", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4453.txt", + key="RFC 4453", + abstract={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.}, + keywords="sip extensions", + doi="10.17487/RFC4453", + } + +@misc{rfc4454, + author="S. Singh and M. Townsley and C. Pignataro", + title="{Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)}", + howpublished="RFC 4454 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4454", + pages="1--26", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5641", +url="https://www.rfc-editor.org/rfc/rfc4454.txt", + key="RFC 4454", + abstract={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]}, + keywords="extensible tunneling protocol", + doi="10.17487/RFC4454", + } + +@misc{rfc4455, + author="M. Hallak-Stamler and M. Bakke and Y. Lederman and M. Krueger and K. McCloghrie", + title="{Definition of Managed Objects for Small Computer System Interface (SCSI) Entities}", + howpublished="RFC 4455 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4455", + pages="1--88", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4455.txt", + key="RFC 4455", + abstract={This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS-TRACK]}, + keywords="mib, management information base, scsi-mib", + doi="10.17487/RFC4455", + } + +@misc{rfc4456, + author="T. Bates and E. Chen and R. Chandra", + title="{BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)}", + howpublished="RFC 4456 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4456", + pages="1--12", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7606", +url="https://www.rfc-editor.org/rfc/rfc4456.txt", + key="RFC 4456", + abstract={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. This document describes the use and design of a method known as ``route reflection'' to alleviate the need for ``full mesh'' Internal BGP (IBGP). This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]}, + keywords="BGP-RR, Border, Gateway, Protocol, autonomous, system", + doi="10.17487/RFC4456", + } + +@misc{rfc4457, + author="G. Camarillo and G. Blanco", + title="{The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)}", + howpublished="RFC 4457 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4457", + pages="1--8", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4457.txt", + key="RFC 4457", + abstract={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.}, + keywords="3gpp, third generation partnership project, 3rd generation partnership project, ims, ip multimedia subsystem", + doi="10.17487/RFC4457", + } + +@misc{rfc4458, + author="C. Jennings and F. Audet and J. Elwell", + title="{Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)}", + howpublished="RFC 4458 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4458", + pages="1--21", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8119", +url="https://www.rfc-editor.org/rfc/rfc4458.txt", + key="RFC 4458", + abstract={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.}, + keywords="universal resource identifiers", + doi="10.17487/RFC4458", + } + +@misc{rfc4459, + author="P. Savola", + title="{MTU and Fragmentation Issues with In-the-Network Tunneling}", + howpublished="RFC 4459 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4459", + pages="1--14", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4459.txt", + key="RFC 4459", + abstract={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.}, + doi="10.17487/RFC4459", + } + +@misc{rfc4460, + author="R. Stewart and I. Arias-Rodriguez and K. Poon and A. Caro and M. Tuexen", + title="{Stream Control Transmission Protocol (SCTP) Specification Errata and Issues}", + howpublished="RFC 4460 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4460", + pages="1--109", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4460.txt", + key="RFC 4460", + abstract={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.}, + keywords="SCTP, IP, internet, transport, packet, network", + doi="10.17487/RFC4460", + } + +@misc{rfc4461, + author="S. {Yasukawa (Ed.)}", + title="{Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)}", + howpublished="RFC 4461 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4461", + pages="1--30", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4461.txt", + key="RFC 4461", + abstract={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). There is no intent to specify solution-specific details or application-specific requirements in this document. 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.}, + keywords="p2mp, multiprotocol label switching", + doi="10.17487/RFC4461", + } + +@misc{rfc4462, + author="J. Hutzelman and J. Salowey and J. Galbraith and V. Welch", + title="{Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol}", + howpublished="RFC 4462 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4462", + pages="1--29", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4462.txt", + key="RFC 4462", + abstract={The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion. 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. 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]}, + keywords="", + doi="10.17487/RFC4462", + } + +@misc{rfc4463, + author="S. Shanmugham and P. Monaco and B. Eberman", + title="{A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks}", + howpublished="RFC 4463 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4463", + pages="1--86", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4463.txt", + key="RFC 4463", + abstract={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. 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.}, + doi="10.17487/RFC4463", + } + +@misc{rfc4464, + author="A. Surtees and M. West", + title="{Signaling Compression (SigComp) Users' Guide}", + howpublished="RFC 4464 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4464", + pages="1--43", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4464.txt", + key="RFC 4464", + abstract={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.}, + doi="10.17487/RFC4464", + } + +@misc{rfc4465, + author="A. Surtees and M. West", + title="{Signaling Compression (SigComp) Torture Tests}", + howpublished="RFC 4465 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4465", + pages="1--68", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4465.txt", + key="RFC 4465", + abstract={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.}, + keywords="SigComp Universal Decompressor Virtual Machine", + doi="10.17487/RFC4465", + } + +@misc{rfc4466, + author="A. Melnikov and C. Daboo", + title="{Collected Extensions to IMAP4 ABNF}", + howpublished="RFC 4466 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4466", + pages="1--17", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6237, 7377", +url="https://www.rfc-editor.org/rfc/rfc4466.txt", + key="RFC 4466", + abstract={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. 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. 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]}, + keywords="", + doi="10.17487/RFC4466", + } + +@misc{rfc4467, + author="M. Crispin", + title="{Internet Message Access Protocol (IMAP) - URLAUTH Extension}", + howpublished="RFC 4467 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4467", + pages="1--18", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5092, 5550", +url="https://www.rfc-editor.org/rfc/rfc4467.txt", + key="RFC 4467", + abstract={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. An IMAP server that supports this extension indicates this with a capability name of ``URLAUTH''. [STANDARDS-TRACK]}, + keywords="imap url, imapurl", + doi="10.17487/RFC4467", + } + +@misc{rfc4468, + author="C. Newman", + title="{Message Submission BURL Extension}", + howpublished="RFC 4468 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4468", + pages="1--14", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5248", +url="https://www.rfc-editor.org/rfc/rfc4468.txt", + key="RFC 4468", + abstract={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]}, + keywords="URLAUTH, IMAP, IMAPURL, Forward-without-download, mobile-client, lemonade", + doi="10.17487/RFC4468", + } + +@misc{rfc4469, + author="P. Resnick", + title="{Internet Message Access Protocol (IMAP) CATENATE Extension}", + howpublished="RFC 4469 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4469", + pages="1--13", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5550", +url="https://www.rfc-editor.org/rfc/rfc4469.txt", + key="RFC 4469", + abstract={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]}, + keywords="append", + doi="10.17487/RFC4469", + } + +@misc{rfc4470, + author="S. Weiler and J. Ihren", + title="{Minimally Covering NSEC Records and DNSSEC On-line Signing}", + howpublished="RFC 4470 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4470", + pages="1--8", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4470.txt", + key="RFC 4470", + abstract={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]}, + keywords="dns security, domain name system", + doi="10.17487/RFC4470", + } + +@misc{rfc4471, + author="G. Sisson and B. Laurie", + title="{Derivation of DNS Name Predecessor and Successor}", + howpublished="RFC 4471 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4471", + pages="1--23", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4471.txt", + key="RFC 4471", + abstract={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.}, + keywords="domain namespace, dynamic nsec, dnssec", + doi="10.17487/RFC4471", + } + +@misc{rfc4472, + author="A. Durand and J. Ihren and P. Savola", + title="{Operational Considerations and Issues with IPv6 DNS}", + howpublished="RFC 4472 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4472", + pages="1--29", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4472.txt", + key="RFC 4472", + abstract={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.}, + keywords="domain name system, internet protocol version 6", + doi="10.17487/RFC4472", + } + +@misc{rfc4473, + author="Y. Nomura and R. Walsh and J-P. Luoma and J. Ott and H. Schulzrinne", + title="{Requirements for Internet Media Guides (IMGs)}", + howpublished="RFC 4473 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4473", + pages="1--23", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4473.txt", + key="RFC 4473", + abstract={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.}, + keywords="media-on-deman, multicast", + doi="10.17487/RFC4473", + } + +@misc{rfc4474, + author="J. Peterson and C. Jennings", + title="{Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)}", + howpublished="RFC 4474 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4474", + pages="1--41", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8224", +url="https://www.rfc-editor.org/rfc/rfc4474.txt", + key="RFC 4474", + abstract={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]}, + keywords="security, identity, identity-info", + doi="10.17487/RFC4474", + } + +@misc{rfc4475, + author="R. {Sparks (Ed.)} and A. Hawrylyshen and A. Johnston and J. Rosenberg and H. Schulzrinne", + title="{Session Initiation Protocol (SIP) Torture Test Messages}", + howpublished="RFC 4475 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4475", + pages="1--53", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4475.txt", + key="RFC 4475", + abstract={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.}, + doi="10.17487/RFC4475", + } + +@misc{rfc4476, + author="C. Francis and D. Pinkas", + title="{Attribute Certificate (AC) Policies Extension}", + howpublished="RFC 4476 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4476", + pages="1--11", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4476.txt", + key="RFC 4476", + abstract={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]}, + keywords="acp, attribute certificate policies", + doi="10.17487/RFC4476", + } + +@misc{rfc4477, + author="T. Chown and S. Venaas and C. Strauf", + title="{Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues}", + howpublished="RFC 4477 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4477", + pages="1--14", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4477.txt", + key="RFC 4477", + abstract={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.}, + keywords="internet protocol", + doi="10.17487/RFC4477", + } + +@misc{rfc4478, + author="Y. Nir", + title="{Repeated Authentication in Internet Key Exchange (IKEv2) Protocol}", + howpublished="RFC 4478 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4478", + pages="1--5", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4478.txt", + key="RFC 4478", + abstract={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.}, + keywords="lifetime", + doi="10.17487/RFC4478", + } + +@misc{rfc4479, + author="J. Rosenberg", + title="{A Data Model for Presence}", + howpublished="RFC 4479 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4479", + pages="1--35", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4479.txt", + key="RFC 4479", + abstract={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]}, + keywords="simple, sip, session initiation protocol", + doi="10.17487/RFC4479", + } + +@misc{rfc4480, + author="H. Schulzrinne and V. Gurbani and P. Kyzivat and J. Rosenberg", + title="{RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)}", + howpublished="RFC 4480 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4480", + pages="1--37", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4480.txt", + key="RFC 4480", + abstract={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. 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 i t offers, an icon reflecting the presentity's status, and the overall role of the presentity. These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4480", + } + +@misc{rfc4481, + author="H. Schulzrinne", + title="{Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals}", + howpublished="RFC 4481 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4481", + pages="1--9", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4481.txt", + key="RFC 4481", + abstract={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 (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4481", + } + +@misc{rfc4482, + author="H. Schulzrinne", + title="{CIPID: Contact Information for the Presence Information Data Format}", + howpublished="RFC 4482 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4482", + pages="1--11", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4482.txt", + key="RFC 4482", + abstract={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]}, + keywords="pidf", + doi="10.17487/RFC4482", + } + +@misc{rfc4483, + author="E. {Burger (Ed.)}", + title="{A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages}", + howpublished="RFC 4483 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4483", + pages="1--17", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4483.txt", + key="RFC 4483", + abstract={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]}, + keywords="universal resource locator, mime, external-body access-type", + doi="10.17487/RFC4483", + } + +@misc{rfc4484, + author="J. Peterson and J. Polk and D. Sicker and H. Tschofenig", + title="{Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)}", + howpublished="RFC 4484 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4484", + pages="1--15", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4484.txt", + key="RFC 4484", + abstract={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.}, + keywords="policy decision", + doi="10.17487/RFC4484", + } + +@misc{rfc4485, + author="J. Rosenberg and H. Schulzrinne", + title="{Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)}", + howpublished="RFC 4485 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4485", + pages="1--23", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4485.txt", + key="RFC 4485", + abstract={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.}, + keywords="interactive communication", + doi="10.17487/RFC4485", + } + +@misc{rfc4486, + author="E. Chen and V. Gillet", + title="{Subcodes for BGP Cease Notification Message}", + howpublished="RFC 4486 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4486", + pages="1--6", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8203", +url="https://www.rfc-editor.org/rfc/rfc4486.txt", + key="RFC 4486", + abstract={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]}, + keywords="border gateway protocol, bgp peers", + doi="10.17487/RFC4486", + } + +@misc{rfc4487, + author="F. Le and S. Faccin and B. Patil and H. Tschofenig", + title="{Mobile IPv6 and Firewalls: Problem Statement}", + howpublished="RFC 4487 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4487", + pages="1--16", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4487.txt", + key="RFC 4487", + abstract={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. 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.}, + keywords="3g, mobile networks", + doi="10.17487/RFC4487", + } + +@misc{rfc4488, + author="O. Levin", + title="{Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription}", + howpublished="RFC 4488 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4488", + pages="1--8", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4488.txt", + key="RFC 4488", + abstract={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]}, + keywords="", + doi="10.17487/RFC4488", + } + +@misc{rfc4489, + author="J-S. Park and M-K. Shin and H-J. Kim", + title="{A Method for Generating Link-Scoped IPv6 Multicast Addresses}", + howpublished="RFC 4489 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4489", + pages="1--6", + year=2006, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4489.txt", + key="RFC 4489", + abstract={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]}, + keywords="iid, interface identifiers", + doi="10.17487/RFC4489", + } + +@misc{rfc4490, + author="S. {Leontiev (Ed.)} and G. {Chudov (Ed.)}", + 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)}", + howpublished="RFC 4490 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4490", + pages="1--29", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4490.txt", + key="RFC 4490", + abstract={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]}, + keywords="CPCMS, S/MIME, PKIX, X.509, certificate, CRL, revocation, public-key, one-way, hash, block, cipher, encryption, decryption, MAC, HMAC, PRF, wrap, unwrap, UKM, KEK, key, Diffie-Hellman, agreement, transport, parameter, derivation, digest, CBC, counter, mode, digital, signature", + doi="10.17487/RFC4490", + } + +@misc{rfc4491, + author="S. {Leontiev (Ed.)} and D. {Shefanovski (Ed.)}", + 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}", + howpublished="RFC 4491 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4491", + pages="1--20", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4491.txt", + key="RFC 4491", + abstract={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]}, + keywords="PKIX, X.509, CPPK, public-key, one-way hash function, block cipher, encryption, decryption, key derivation, parameter, message digest, digital signature, 34.310, 34.311, 34.310-95, 34.310-2004, 34.311-95", + doi="10.17487/RFC4491", + } + +@misc{rfc4492, + author="S. Blake-Wilson and N. Bolyard and V. Gupta and C. Hawk and B. Moeller", + title="{Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)}", + howpublished="RFC 4492 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4492", + pages="1--35", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8422, updated by RFCs 5246, 7027, 7919", +url="https://www.rfc-editor.org/rfc/rfc4492.txt", + key="RFC 4492", + abstract={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.}, + keywords="ecdh, elliptic curve diffie-hellman, elliptic curve digital signature algorithm, ecdsa", + doi="10.17487/RFC4492", + } + +@misc{rfc4493, + author="JH. Song and R. Poovendran and J. Lee and T. Iwata", + title="{The AES-CMAC Algorithm}", + howpublished="RFC 4493 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4493", + pages="1--20", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4493.txt", + key="RFC 4493", + abstract={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.}, + keywords="cipher-based message authentication code, omac1, one-key cbc mac1, advanced encryption algorithm", + doi="10.17487/RFC4493", + } + +@misc{rfc4494, + author="JH. Song and R. Poovendran and J. Lee", + title="{The AES-CMAC-96 Algorithm and Its Use with IPsec}", + howpublished="RFC 4494 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4494", + pages="1--8", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4494.txt", + key="RFC 4494", + abstract={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]}, + keywords="cipher-basd message authentication code, one-key cbc-mac1, omac1, xcbc, extended cipher block chaining, advanced encryption standard", + doi="10.17487/RFC4494", + } + +@misc{rfc4495, + author="J. Polk and S. Dhesikan", + title="{A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow}", + howpublished="RFC 4495 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4495", + pages="1--21", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4495.txt", + key="RFC 4495", + abstract={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]}, + keywords="rsvpv1", + doi="10.17487/RFC4495", + } + +@misc{rfc4496, + author="M. Stecher and A. Barbir", + title="{Open Pluggable Edge Services (OPES) SMTP Use Cases}", + howpublished="RFC 4496 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4496", + pages="1--12", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4496.txt", + key="RFC 4496", + abstract={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.}, + doi="10.17487/RFC4496", + } + +@misc{rfc4497, + author="J. Elwell and F. Derks and P. Mourot and O. Rousseau", + title="{Interworking between the Session Initiation Protocol (SIP) and QSIG}", + howpublished="RFC 4497 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4497", + pages="1--65", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4497.txt", + key="RFC 4497", + abstract={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.}, + keywords="telecommunication networks, enterprise networks, signalling", + doi="10.17487/RFC4497", + } + +@misc{rfc4498, + author="G. Keeni", + title="{The Managed Object Aggregation MIB}", + howpublished="RFC 4498 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4498", + pages="1--29", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4498.txt", + key="RFC 4498", + abstract={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.}, + keywords="management information base, aggregate mib, time aggregate mib", + doi="10.17487/RFC4498", + } + +@misc{rfc4501, + author="S. Josefsson", + title="{Domain Name System Uniform Resource Identifiers}", + howpublished="RFC 4501 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4501", + pages="1--10", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4501.txt", + key="RFC 4501", + abstract={This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]}, + keywords="dns, uri", + doi="10.17487/RFC4501", + } + +@misc{rfc4502, + author="S. Waldbusser", + title="{Remote Network Monitoring Management Information Base Version 2}", + howpublished="RFC 4502 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4502", + pages="1--142", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4502.txt", + key="RFC 4502", + abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. [STANDARDS-TRACK]}, + keywords="RMON-MIB, RMON, MIB", + doi="10.17487/RFC4502", + } + +@misc{rfc4503, + author="M. Boesgaard and M. Vesterager and E. Zenner", + title="{A Description of the Rabbit Stream Cipher Algorithm}", + howpublished="RFC 4503 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4503", + pages="1--12", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4503.txt", + key="RFC 4503", + abstract={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.}, + keywords="iv, initialization vector, encryption algorithm", + doi="10.17487/RFC4503", + } + +@misc{rfc4504, + author="H. {Sinnreich (Ed.)} and S. Lass and C. Stredicke", + title="{SIP Telephony Device Requirements and Configuration}", + howpublished="RFC 4504 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4504", + pages="1--37", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4504.txt", + key="RFC 4504", + abstract={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. 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.}, + keywords="session initiation protocol, pc, pda, analog", + doi="10.17487/RFC4504", + } + +@misc{rfc4505, + author="K. Zeilenga", + title="{Anonymous Simple Authentication and Security Layer (SASL) Mechanism}", + howpublished="RFC 4505 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4505", + pages="1--9", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4505.txt", + key="RFC 4505", + abstract={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]}, + keywords="SASL-ANON, Simple, Authentication, Security, Layer", + doi="10.17487/RFC4505", + } + +@misc{rfc4506, + author="M. {Eisler (Ed.)}", + title="{XDR: External Data Representation Standard}", + howpublished="RFC 4506 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="4506", + pages="1--27", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4506.txt", + key="RFC 4506", + abstract={This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. [STANDARDS-TRACK]}, + keywords="XDR, rpc, onc, open network computing", + doi="10.17487/RFC4506", + } + +@misc{rfc4507, + author="J. Salowey and H. Zhou and P. Eronen and H. Tschofenig", + title="{Transport Layer Security (TLS) Session Resumption without Server-Side State}", + howpublished="RFC 4507 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4507", + pages="1--17", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5077", +url="https://www.rfc-editor.org/rfc/rfc4507.txt", + key="RFC 4507", + abstract={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]}, + keywords="", + doi="10.17487/RFC4507", + } + +@misc{rfc4508, + author="O. Levin and A. Johnston", + title="{Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method}", + howpublished="RFC 4508 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4508", + pages="1--6", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8217", +url="https://www.rfc-editor.org/rfc/rfc4508.txt", + key="RFC 4508", + abstract={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]}, + keywords="caller preferences", + doi="10.17487/RFC4508", + } + +@misc{rfc4509, + author="W. Hardaker", + title="{Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)}", + howpublished="RFC 4509 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4509", + pages="1--7", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4509.txt", + key="RFC 4509", + abstract={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]}, + keywords="domain name system, dns, dnskey", + doi="10.17487/RFC4509", + } + +@misc{rfc4510, + author="K. {Zeilenga (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map}", + howpublished="RFC 4510 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4510", + pages="1--7", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4510.txt", + key="RFC 4510", + abstract={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]}, + keywords="LDAPV3, LDAv3, x.500, LDAP3-ATD, syntax, LDAP3-UTF8, x.500, ASN.1, string format, STR-LDAP, LDAP-URL, Lightweight Directory Access Protocol, Universal Resource Locator", + doi="10.17487/RFC4510", + } + +@misc{rfc4511, + author="J. {Sermersheim (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): The Protocol}", + howpublished="RFC 4511 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4511", + pages="1--68", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4511.txt", + key="RFC 4511", + abstract={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]}, + keywords="LDAP, TLS, LDAPv3, LDAv3, x.500", + doi="10.17487/RFC4511", + } + +@misc{rfc4512, + author="K. {Zeilenga (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): Directory Information Models}", + howpublished="RFC 4512 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4512", + pages="1--52", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4512.txt", + key="RFC 4512", + abstract={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]}, + keywords="LDAv3, x.500, LDAPv3, LDAP3-ATD, syntax, elective extensions, mechanisms", + doi="10.17487/RFC4512", + } + +@misc{rfc4513, + author="R. {Harrison (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms}", + howpublished="RFC 4513 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4513", + pages="1--34", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4513.txt", + key="RFC 4513", + abstract={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. 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. 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. 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]}, + keywords="LDAP, TLS", + doi="10.17487/RFC4513", + } + +@misc{rfc4514, + author="K. {Zeilenga (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names}", + howpublished="RFC 4514 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4514", + pages="1--15", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4514.txt", + key="RFC 4514", + abstract={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]}, + keywords="LDAP3-UTF8, LDAPv3, x.500, ASN.1, string, format", + doi="10.17487/RFC4514", + } + +@misc{rfc4515, + author="M. {Smith (Ed.)} and T. Howes", + title="{Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters}", + howpublished="RFC 4515 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4515", + pages="1--12", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4515.txt", + key="RFC 4515", + abstract={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]}, + keywords="STR-LDAP, STRLDAP, LDAPv3, X.500, BER, ASN.1", + doi="10.17487/RFC4515", + } + +@misc{rfc4516, + author="M. {Smith (Ed.)} and T. Howes", + title="{Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator}", + howpublished="RFC 4516 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4516", + pages="1--15", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4516.txt", + key="RFC 4516", + abstract={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]}, + keywords="LDAP-URL, LDAPURL, LDAP search, URL, URI, LDAPv3", + doi="10.17487/RFC4516", + } + +@misc{rfc4517, + author="S. {Legg (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules}", + howpublished="RFC 4517 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4517", + pages="1--53", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4517.txt", + key="RFC 4517", + abstract={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]}, + keywords="LDAP3-ATD, LDAv3, x.500, syntax,", + doi="10.17487/RFC4517", + } + +@misc{rfc4518, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation}", + howpublished="RFC 4518 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4518", + pages="1--14", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4518.txt", + key="RFC 4518", + abstract={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]}, + keywords="", + doi="10.17487/RFC4518", + } + +@misc{rfc4519, + author="A. {Sciberras (Ed.)}", + title="{Lightweight Directory Access Protocol (LDAP): Schema for User Applications}", + howpublished="RFC 4519 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4519", + pages="1--35", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4519.txt", + key="RFC 4519", + abstract={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]}, + keywords="Lightweight Directory Access Protocol, syntax", + doi="10.17487/RFC4519", + } + +@misc{rfc4520, + author="K. Zeilenga", + title="{Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)}", + howpublished="RFC 4520 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4520", + pages="1--19", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4520.txt", + key="RFC 4520", + abstract={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.}, + keywords="", + doi="10.17487/RFC4520", + } + +@misc{rfc4521, + author="K. Zeilenga", + title="{Considerations for Lightweight Directory Access Protocol (LDAP) Extensions}", + howpublished="RFC 4521 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4521", + pages="1--16", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4521.txt", + key="RFC 4521", + abstract={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.}, + keywords="", + doi="10.17487/RFC4521", + } + +@misc{rfc4522, + author="S. Legg", + title="{Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option}", + howpublished="RFC 4522 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4522", + pages="1--8", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4522.txt", + key="RFC 4522", + abstract={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]}, + keywords="ber, ldap-specific encoding", + doi="10.17487/RFC4522", + } + +@misc{rfc4523, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates}", + howpublished="RFC 4523 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4523", + pages="1--24", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4523.txt", + key="RFC 4523", + abstract={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]}, + keywords="LDAP3-ATD, LDAv3, x.500, syntax, pkix", + doi="10.17487/RFC4523", + } + +@misc{rfc4524, + author="K. {Zeilenga (Ed.)}", + title="{COSINE LDAP/X.500 Schema}", + howpublished="RFC 4524 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4524", + pages="1--25", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4524.txt", + key="RFC 4524", + abstract={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. This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. [STANDARDS-TRACK]}, + keywords="Naming", + doi="10.17487/RFC4524", + } + +@misc{rfc4525, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension}", + howpublished="RFC 4525 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4525", + pages="1--6", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4525.txt", + key="RFC 4525", + abstract={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.}, + keywords="pre-read, post-read, control extension", + doi="10.17487/RFC4525", + } + +@misc{rfc4526, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters}", + howpublished="RFC 4526 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4526", + pages="1--5", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4526.txt", + key="RFC 4526", + abstract={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]}, + keywords="x.500, string representation", + doi="10.17487/RFC4526", + } + +@misc{rfc4527, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Read Entry Controls}", + howpublished="RFC 4527 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4527", + pages="1--8", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4527.txt", + key="RFC 4527", + abstract={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]}, + keywords="", + doi="10.17487/RFC4527", + } + +@misc{rfc4528, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Assertion Control}", + howpublished="RFC 4528 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4528", + pages="1--6", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4528.txt", + key="RFC 4528", + abstract={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]}, + keywords="test and set, test and clear", + doi="10.17487/RFC4528", + } + +@misc{rfc4529, + author="K. Zeilenga", + title="{Requesting Attributes by Object Class in the Lightweight Directory Access Protocol}", + howpublished="RFC 4529 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4529", + pages="1--6", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4529.txt", + key="RFC 4529", + abstract={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.}, + doi="10.17487/RFC4529", + } + +@misc{rfc4530, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute}", + howpublished="RFC 4530 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4530", + pages="1--8", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4530.txt", + key="RFC 4530", + abstract={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]}, + keywords="x.500, universally unique identifier", + doi="10.17487/RFC4530", + } + +@misc{rfc4531, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Turn Operation}", + howpublished="RFC 4531 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4531", + pages="1--9", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4531.txt", + key="RFC 4531", + abstract={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.}, + keywords="turn request, turn response", + doi="10.17487/RFC4531", + } + +@misc{rfc4532, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) ``Who am I?'' Operation}", + howpublished="RFC 4532 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4532", + pages="1--7", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4532.txt", + key="RFC 4532", + abstract={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]}, + keywords="authorization identity", + doi="10.17487/RFC4532", + } + +@misc{rfc4533, + author="K. Zeilenga and J.H. Choi", + title="{The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation}", + howpublished="RFC 4533 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4533", + pages="1--32", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4533.txt", + key="RFC 4533", + abstract={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.}, + keywords="dit, directory information tree", + doi="10.17487/RFC4533", + } + +@misc{rfc4534, + author="A Colegrove and H Harney", + title="{Group Security Policy Token v1}", + howpublished="RFC 4534 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4534", + pages="1--33", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4534.txt", + key="RFC 4534", + abstract={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]}, + keywords="cryptographic group", + doi="10.17487/RFC4534", + } + +@misc{rfc4535, + author="H. Harney and U. Meth and A. Colegrove and G. Gross", + title="{GSAKMP: Group Secure Association Key Management Protocol}", + howpublished="RFC 4535 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4535", + pages="1--106", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4535.txt", + key="RFC 4535", + abstract={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]}, + keywords="security framework, cryptographic network", + doi="10.17487/RFC4535", + } + +@misc{rfc4536, + author="P. Hoschka", + title="{The application/smil and application/smil+xml Media Types}", + howpublished="RFC 4536 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4536", + pages="1--8", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4536.txt", + key="RFC 4536", + abstract={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.}, + keywords="synchronized multimedia integration language", + doi="10.17487/RFC4536", + } + +@misc{rfc4537, + author="L. Zhu and P. Leach and K. Jaganathan", + title="{Kerberos Cryptosystem Negotiation Extension}", + howpublished="RFC 4537 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4537", + pages="1--6", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4537.txt", + key="RFC 4537", + abstract={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]}, + keywords="", + doi="10.17487/RFC4537", + } + +@misc{rfc4538, + author="J. Rosenberg", + title="{Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)}", + howpublished="RFC 4538 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4538", + pages="1--17", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4538.txt", + key="RFC 4538", + abstract={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]}, + keywords="tdialog", + doi="10.17487/RFC4538", + } + +@misc{rfc4539, + author="T. Edwards", + title="{Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF)}", + howpublished="RFC 4539 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4539", + pages="1--6", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4539.txt", + key="RFC 4539", + abstract={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.}, + doi="10.17487/RFC4539", + } + +@misc{rfc4540, + author="M. Stiemerling and J. Quittek and C. Cadar", + title="{NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0}", + howpublished="RFC 4540 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4540", + pages="1--67", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4540.txt", + key="RFC 4540", + abstract={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.}, + keywords="midcom", + doi="10.17487/RFC4540", + } + +@misc{rfc4541, + author="M. Christensen and K. Kimball and F. Solensky", + title="{Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches}", + howpublished="RFC 4541 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4541", + pages="1--16", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4541.txt", + key="RFC 4541", + abstract={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.}, + keywords="igmpv3, mldv2", + doi="10.17487/RFC4541", + } + +@misc{rfc4542, + author="F. Baker and J. Polk", + title="{Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite}", + howpublished="RFC 4542 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4542", + pages="1--42", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5865", +url="https://www.rfc-editor.org/rfc/rfc4542.txt", + key="RFC 4542", + abstract={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. 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 informa tion for the Internet community.}, + keywords="ieps, internet emergency preparedness service, call admission control, cac, phb, per hop behavior, multi-level precedence and preemption, mlpp, government emergency telecommunication service, gets", + doi="10.17487/RFC4542", + } + +@misc{rfc4543, + author="D. McGrew and J. Viega", + title="{The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH}", + howpublished="RFC 4543 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4543", + pages="1--14", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4543.txt", + key="RFC 4543", + abstract={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]}, + keywords="encapsulating security payload, gcm, galois/counter mode, authentication header", + doi="10.17487/RFC4543", + } + +@misc{rfc4544, + author="M. Bakke and M. Krueger and T. McSweeney and J. Muchow", + title="{Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)}", + howpublished="RFC 4544 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4544", + pages="1--83", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7147", +url="https://www.rfc-editor.org/rfc/rfc4544.txt", + key="RFC 4544", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [STANDARDS-TRACK]}, + keywords="tcp/ip, scsi", + doi="10.17487/RFC4544", + } + +@misc{rfc4545, + author="M. Bakke and J. Muchow", + title="{Definitions of Managed Objects for IP Storage User Identity Authorization}", + howpublished="RFC 4545 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4545", + pages="1--43", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4545.txt", + key="RFC 4545", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing 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]}, + keywords="mib, management information base, snmp, tcp/ip, ips-auth-mib", + doi="10.17487/RFC4545", + } + +@misc{rfc4546, + author="D. Raftus and E. Cardona", + title="{Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces}", + howpublished="RFC 4546 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4546", + pages="1--139", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4546.txt", + key="RFC 4546", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). [STANDARDS-TRACK]}, + keywords="cmts, cm, upstream, downstream, tdma, atdma, scdma, quality of service, channel utilizazation", + doi="10.17487/RFC4546", + } + +@misc{rfc4547, + author="A. Ahmad and G. Nakanishi", + title="{Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems}", + howpublished="RFC 4547 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4547", + pages="1--40", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4547.txt", + key="RFC 4547", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for 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. 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]}, + keywords="snmp, simple network management protocol, mib, smiv2, DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB", + doi="10.17487/RFC4547", + } + +@misc{rfc4548, + author="E. Gray and J. Rutemiller and G. Swallow", + title="{Internet Code Point (ICP) Assignments for NSAP Addresses}", + howpublished="RFC 4548 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4548", + pages="1--9", + year=2006, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4548.txt", + key="RFC 4548", + abstract={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]}, + keywords="network service access point", + doi="10.17487/RFC4548", + } + +@misc{rfc4549, + author="A. {Melnikov (Ed.)}", + title="{Synchronization Operations for Disconnected IMAP4 Clients}", + howpublished="RFC 4549 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4549", + pages="1--35", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4549.txt", + key="RFC 4549", + abstract={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. 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. 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.}, + keywords="internet message access protocol", + doi="10.17487/RFC4549", + } + +@misc{rfc4550, + author="S. Maes and A. Melnikov", + title="{Internet Email to Support Diverse Service Environments (Lemonade) Profile}", + howpublished="RFC 4550 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4550", + pages="1--23", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5550", +url="https://www.rfc-editor.org/rfc/rfc4550.txt", + key="RFC 4550", + abstract={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. 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]}, + keywords="internet message access protocol,", + doi="10.17487/RFC4550", + } + +@misc{rfc4551, + author="A. Melnikov and S. Hole", + title="{IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization}", + howpublished="RFC 4551 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4551", + pages="1--25", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7162", +url="https://www.rfc-editor.org/rfc/rfc4551.txt", + key="RFC 4551", + abstract={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. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]}, + keywords="internet mail access protocol", + doi="10.17487/RFC4551", + } + +@misc{rfc4552, + author="M. Gupta and N. Melam", + title="{Authentication/Confidentiality for OSPFv3}", + howpublished="RFC 4552 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4552", + pages="1--15", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4552.txt", + key="RFC 4552", + abstract={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]}, + keywords="open shortest path first, authentication header, encapsulating security payload, ah/esp", + doi="10.17487/RFC4552", + } + +@misc{rfc4553, + author="A. {Vainshtein (Ed.)} and YJ. {Stein (Ed.)}", + title="{Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)}", + howpublished="RFC 4553 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4553", + pages="1--27", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4553.txt", + key="RFC 4553", + abstract={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]}, + keywords="SAToP, pseudowires, circuit emulation, structure-agnostic emulation", + doi="10.17487/RFC4553", + } + +@misc{rfc4554, + author="T. Chown", + title="{Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks}", + howpublished="RFC 4554 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4554", + pages="1--11", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4554.txt", + key="RFC 4554", + abstract={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.}, + keywords="Virtual Local Area Network", + doi="10.17487/RFC4554", + } + +@misc{rfc4555, + author="P. Eronen", + title="{IKEv2 Mobility and Multihoming Protocol (MOBIKE)}", + howpublished="RFC 4555 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4555", + pages="1--33", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4555.txt", + key="RFC 4555", + abstract={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]}, + keywords="internet key exchange, ipsec, internet protocol security, vpn, virtual private networks", + doi="10.17487/RFC4555", + } + +@misc{rfc4556, + author="L. Zhu and B. Tung", + title="{Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)}", + howpublished="RFC 4556 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4556", + pages="1--42", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6112, 8062", +url="https://www.rfc-editor.org/rfc/rfc4556.txt", + key="RFC 4556", + abstract={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]}, + keywords="", + doi="10.17487/RFC4556", + } + +@misc{rfc4557, + author="L. Zhu and K. Jaganathan and N. Williams", + title="{Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)}", + howpublished="RFC 4557 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4557", + pages="1--6", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4557.txt", + key="RFC 4557", + abstract={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]}, + keywords="", + doi="10.17487/RFC4557", + } + +@misc{rfc4558, + author="Z. Ali and R. Rahman and D. Prairie and D. Papadimitriou", + title="{Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement}", + howpublished="RFC 4558 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4558", + pages="1--7", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4558.txt", + key="RFC 4558", + abstract={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]}, + keywords="Multi-Protocol Label Switching, mpls, Generalized Multi-Protocol Label Switching, gmpls, Traffic Engineering, te, rsvp-te, gr, graceful restart", + doi="10.17487/RFC4558", + } + +@misc{rfc4559, + author="K. Jaganathan and L. Zhu and J. Brezak", + title="{SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows}", + howpublished="RFC 4559 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4559", + pages="1--8", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4559.txt", + key="RFC 4559", + abstract={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.}, + keywords="msie, microsoft internet explorer, iis, internet information services, simple and protected negotiate, nt lan manager", + doi="10.17487/RFC4559", + } + +@misc{rfc4560, + author="J. {Quittek (Ed.)} and K. {White (Ed.)}", + title="{Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations}", + howpublished="RFC 4560 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4560", + pages="1--100", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4560.txt", + key="RFC 4560", + abstract={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. 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]}, + keywords="mib, management information base, DISMAN-PING-MIB DEFINITIONS, DISMAN-TRACEROUTE-MIB DEFINITIONS, DISMAN-NSLOOKUP-MIB DEFINITIONS", + doi="10.17487/RFC4560", + } + +@misc{rfc4561, + author="J.-P. {Vasseur (Ed.)} and Z. Ali and S. Sivabalan", + title="{Definition of a Record Route Object (RRO) Node-Id Sub-Object}", + howpublished="RFC 4561 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4561", + pages="1--10", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4561.txt", + key="RFC 4561", + abstract={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 Rerout e method. [STANDARDS-TRACK]}, + keywords="multiprotocol label switching traffic engineering, plr, point of local repair, igp, interior gateway protocol, as, autonomous system, abr, area border router, asbr, autonomous system border router", + doi="10.17487/RFC4561", + } + +@misc{rfc4562, + author="T. Melsen and S. Blake", + title="{MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network}", + howpublished="RFC 4562 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4562", + pages="1--13", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4562.txt", + key="RFC 4562", + abstract={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. 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.}, + keywords="Ethernet, Access Network, ARP, DHCP", + doi="10.17487/RFC4562", + } + +@misc{rfc4563, + author="E. Carrara and V. Lehtovirta and K. Norrman", + title="{The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)}", + howpublished="RFC 4563 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4563", + pages="1--10", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6309", +url="https://www.rfc-editor.org/rfc/rfc4563.txt", + key="RFC 4563", + abstract={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]}, + keywords="security, key management, multicast, broadcast, MBMS", + doi="10.17487/RFC4563", + } + +@misc{rfc4564, + author="S. {Govindan (Ed.)} and H. Cheng and ZH. Yao and WH. Zhou and L. Yang", + title="{Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)}", + howpublished="RFC 4564 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4564", + pages="1--32", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4564.txt", + key="RFC 4564", + abstract={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.}, + keywords="wlan, wireless local area network", + doi="10.17487/RFC4564", + } + +@misc{rfc4565, + author="D. Loher and D. Nelson and O. Volinsky and B. Sarikaya", + title="{Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols}", + howpublished="RFC 4565 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4565", + pages="1--31", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4565.txt", + key="RFC 4565", + abstract={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.}, + doi="10.17487/RFC4565", + } + +@misc{rfc4566, + author="M. Handley and V. Jacobson and C. Perkins", + title="{SDP: Session Description Protocol}", + howpublished="RFC 4566 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4566", + pages="1--49", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4566.txt", + key="RFC 4566", + abstract={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]}, + keywords="SDP, mbone, internet, multicast, backbone, multimedia, internet addresses syntax", + doi="10.17487/RFC4566", + } + +@misc{rfc4567, + author="J. Arkko and F. Lindholm and M. Naslund and K. Norrman and E. Carrara", + title="{Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)}", + howpublished="RFC 4567 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4567", + pages="1--30", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4567.txt", + key="RFC 4567", + abstract={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. 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]}, + keywords="key management protocol, multimedia internet keying, mikey", + doi="10.17487/RFC4567", + } + +@misc{rfc4568, + author="F. Andreasen and M. Baugher and D. Wing", + title="{Session Description Protocol (SDP) Security Descriptions for Media Streams}", + howpublished="RFC 4568 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4568", + pages="1--44", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4568.txt", + key="RFC 4568", + abstract={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]}, + keywords="srtp, secure real-time transport protocol", + doi="10.17487/RFC4568", + } + +@misc{rfc4569, + author="G. Camarillo", + title="{Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag}", + howpublished="RFC 4569 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4569", + pages="1--4", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4569.txt", + key="RFC 4569", + abstract={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.}, + doi="10.17487/RFC4569", + } + +@misc{rfc4570, + author="B. Quinn and R. Finlayson", + title="{Session Description Protocol (SDP) Source Filters}", + howpublished="RFC 4570 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4570", + pages="1--14", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4570.txt", + key="RFC 4570", + abstract={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]}, + keywords="internet protocol, ip, source-filter, ssm, source-specific multicast", + doi="10.17487/RFC4570", + } + +@misc{rfc4571, + author="J. Lazzaro", + title="{Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport}", + howpublished="RFC 4571 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4571", + pages="1--9", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4571.txt", + key="RFC 4571", + abstract={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]}, + keywords="TCP-based media transport, TCP tunnel, transmission control protocol", + doi="10.17487/RFC4571", + } + +@misc{rfc4572, + author="J. Lennox", + title="{Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)}", + howpublished="RFC 4572 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4572", + pages="1--17", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8122", +url="https://www.rfc-editor.org/rfc/rfc4572.txt", + key="RFC 4572", + abstract={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. This document extends and updates RFC 4145. [STANDARDS-TRACK]}, + keywords="setup, connection, reestablishment", + doi="10.17487/RFC4572", + } + +@misc{rfc4573, + author="R. Even and A. Lochbaum", + title="{MIME Type Registration for RTP Payload Format for H.224}", + howpublished="RFC 4573 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4573", + pages="1--7", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4573.txt", + key="RFC 4573", + abstract={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]}, + keywords="real time transport protocol, itu h.281, h.224, far-end camera control", + doi="10.17487/RFC4573", + } + +@misc{rfc4574, + author="O. Levin and G. Camarillo", + title="{The Session Description Protocol (SDP) Label Attribute}", + howpublished="RFC 4574 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4574", + pages="1--8", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4574.txt", + key="RFC 4574", + abstract={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]}, + keywords="media level attribute, media stream", + doi="10.17487/RFC4574", + } + +@misc{rfc4575, + author="J. Rosenberg and H. Schulzrinne and O. {Levin (Ed.)}", + title="{A Session Initiation Protocol (SIP) Event Package for Conference State}", + howpublished="RFC 4575 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4575", + pages="1--48", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4575.txt", + key="RFC 4575", + abstract={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]}, + keywords="conference event package, uri, uniform resource identifier", + doi="10.17487/RFC4575", + } + +@misc{rfc4576, + author="E. Rosen and P. Psenak and P. Pillay-Esnault", + title="{Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)}", + howpublished="RFC 4576 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4576", + pages="1--7", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4576.txt", + key="RFC 4576", + abstract={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]}, + keywords="service provider, sp, provider edge, pe", + doi="10.17487/RFC4576", + } + +@misc{rfc4577, + author="E. Rosen and P. Psenak and P. Pillay-Esnault", + title="{OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)}", + howpublished="RFC 4577 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4577", + pages="1--25", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4577.txt", + key="RFC 4577", + abstract={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. This document updates RFC 4364. [STANDARDS-TRACK]}, + keywords="ce, open shortest path first, mpls, Multiprotocol Label Switching", + doi="10.17487/RFC4577", + } + +@misc{rfc4578, + author="M. Johnston and S. {Venaas (Ed.)}", + title="{Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)}", + howpublished="RFC 4578 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4578", + pages="1--7", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4578.txt", + key="RFC 4578", + abstract={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.}, + keywords="efi, extensible firmware interface", + doi="10.17487/RFC4578", + } + +@misc{rfc4579, + author="A. Johnston and O. Levin", + title="{Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents}", + howpublished="RFC 4579 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4579", + pages="1--43", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4579.txt", + key="RFC 4579", + abstract={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.}, + keywords="ua, conference-unaware, conference-aware, focus", + doi="10.17487/RFC4579", + } + +@misc{rfc4580, + author="B. Volz", + title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option}", + howpublished="RFC 4580 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4580", + pages="1--6", + year=2006, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4580.txt", + key="RFC 4580", + abstract={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]}, + keywords="", + doi="10.17487/RFC4580", + } + +@misc{rfc4581, + author="M. Bagnulo and J. Arkko", + title="{Cryptographically Generated Addresses (CGA) Extension Field Format}", + howpublished="RFC 4581 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4581", + pages="1--4", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4581.txt", + key="RFC 4581", + abstract={This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS-TRACK]}, + keywords="tlv", + doi="10.17487/RFC4581", + } + +@misc{rfc4582, + author="G. Camarillo and J. Ott and K. Drage", + title="{The Binary Floor Control Protocol (BFCP)}", + howpublished="RFC 4582 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4582", + pages="1--65", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4582.txt", + key="RFC 4582", + abstract={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 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]}, + keywords="conference", + doi="10.17487/RFC4582", + } + +@misc{rfc4583, + author="G. Camarillo", + title="{Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams}", + howpublished="RFC 4583 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4583", + pages="1--12", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4583.txt", + key="RFC 4583", + abstract={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]}, + keywords="bfcp stream", + doi="10.17487/RFC4583", + } + +@misc{rfc4584, + author="S. Chakrabarti and E. Nordmark", + title="{Extension to Sockets API for Mobile IPv6}", + howpublished="RFC 4584 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4584", + pages="1--25", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4584.txt", + key="RFC 4584", + abstract={This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6. 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.}, + keywords="advanced socket api, mobility header messages, hom address destination, routing header type 2, socket applications", + doi="10.17487/RFC4584", + } + +@misc{rfc4585, + author="J. Ott and S. Wenger and N. Sato and C. Burmeister and J. Rey", + title="{Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)}", + howpublished="RFC 4585 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4585", + pages="1--51", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5506, 8108", +url="https://www.rfc-editor.org/rfc/rfc4585.txt", + key="RFC 4585", + abstract={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]}, + keywords="media stream, feedback based error, audio visual profile", + doi="10.17487/RFC4585", + } + +@misc{rfc4586, + author="C. Burmeister and R. Hakenberg and A. Miyazaki and J. Ott and N. Sato and S. Fukunaga", + title="{Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations}", + howpublished="RFC 4586 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4586", + pages="1--28", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4586.txt", + key="RFC 4586", + abstract={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.}, + keywords="Real-time Transport Protocol", + doi="10.17487/RFC4586", + } + +@misc{rfc4587, + author="R. Even", + title="{RTP Payload Format for H.261 Video Streams}", + howpublished="RFC 4587 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4587", + pages="1--17", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4587.txt", + key="RFC 4587", + abstract={This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. 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. This specification obsoletes RFC 2032. [STANDARDS-TRACK]}, + keywords="RTP-H.261, real-time transport protocol, sdp, session description protocol", + doi="10.17487/RFC4587", + } + +@misc{rfc4588, + author="J. Rey and D. Leon and A. Miyazaki and V. Varsa and R. Hakenberg", + title="{RTP Retransmission Payload Format}", + howpublished="RFC 4588 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4588", + pages="1--35", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4588.txt", + key="RFC 4588", + abstract={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]}, + keywords="real time transport protocol, rtcp, real-time transport control protocol, RTP/AVPF", + doi="10.17487/RFC4588", + } + +@misc{rfc4589, + author="H. Schulzrinne and H. Tschofenig", + title="{Location Types Registry}", + howpublished="RFC 4589 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4589", + pages="1--12", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4589.txt", + key="RFC 4589", + abstract={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]}, + keywords="", + doi="10.17487/RFC4589", + } + +@misc{rfc4590, + author="B. Sterman and D. Sadolevsky and D. Schwartz and D. Williams and W. Beck", + title="{RADIUS Extension for Digest Authentication}", + howpublished="RFC 4590 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4590", + pages="1--32", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5090", +url="https://www.rfc-editor.org/rfc/rfc4590.txt", + key="RFC 4590", + abstract={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]}, + keywords="remote authentication dial-in user service, sip, http", + doi="10.17487/RFC4590", + } + +@misc{rfc4591, + author="M. Townsley and G. Wilkie and S. Booth and S. Bryant and J. Lau", + title="{Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)}", + howpublished="RFC 4591 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4591", + pages="1--14", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5641", +url="https://www.rfc-editor.org/rfc/rfc4591.txt", + key="RFC 4591", + abstract={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]}, + keywords="data link protocols, frame encapsulation, virtual-circuit creation and deletion, status change notification", + doi="10.17487/RFC4591", + } + +@misc{rfc4592, + author="E. Lewis", + title="{The Role of Wildcards in the Domain Name System}", + howpublished="RFC 4592 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4592", + pages="1--20", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4592.txt", + key="RFC 4592", + abstract={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]}, + keywords="cname", + doi="10.17487/RFC4592", + } + +@misc{rfc4593, + author="A. Barbir and S. Murphy and Y. Yang", + title="{Generic Threats to Routing Protocols}", + howpublished="RFC 4593 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4593", + pages="1--22", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4593.txt", + key="RFC 4593", + abstract={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.}, + keywords="threat sources, threat capability, threat action, threat consequences", + doi="10.17487/RFC4593", + } + +@misc{rfc4594, + author="J. Babiarz and K. Chan and F. Baker", + title="{Configuration Guidelines for DiffServ Service Classes}", + howpublished="RFC 4594 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4594", + pages="1--57", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5865", +url="https://www.rfc-editor.org/rfc/rfc4594.txt", + key="RFC 4594", + abstract={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.}, + keywords="differentiated services code points, traffic conditioners, per-hop behaviors, phb, dscp, active queue management, aqm", + doi="10.17487/RFC4594", + } + +@misc{rfc4595, + author="F. Maino and D. Black", + title="{Use of IKEv2 in the Fibre Channel Security Association Management Protocol}", + howpublished="RFC 4595 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4595", + pages="1--16", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4595.txt", + key="RFC 4595", + abstract={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.}, + keywords="internet key exchange", + doi="10.17487/RFC4595", + } + +@misc{rfc4596, + author="J. Rosenberg and P. Kyzivat", + title="{Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension}", + howpublished="RFC 4596 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4596", + pages="1--40", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4596.txt", + key="RFC 4596", + abstract={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.}, + doi="10.17487/RFC4596", + } + +@misc{rfc4597, + author="R. Even and N. Ismail", + title="{Conferencing Scenarios}", + howpublished="RFC 4597 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4597", + pages="1--17", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4597.txt", + key="RFC 4597", + abstract={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.}, + keywords="multimedia, voice, video, text, interactive text, xcon", + doi="10.17487/RFC4597", + } + +@misc{rfc4598, + author="B. Link", + title="{Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio}", + howpublished="RFC 4598 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4598", + pages="1--17", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4598.txt", + key="RFC 4598", + abstract={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]}, + keywords="encoded audio data, multichannel audio coding format", + doi="10.17487/RFC4598", + } + +@misc{rfc4601, + author="B. Fenner and M. Handley and H. Holbrook and I. Kouvelas", + title="{Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)}", + howpublished="RFC 4601 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4601", + pages="1--150", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7761, updated by RFCs 5059, 5796, 6226", +url="https://www.rfc-editor.org/rfc/rfc4601.txt", + key="RFC 4601", + abstract={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. This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]}, + keywords="PIM-SM, routing, message, type, timers, flags", + doi="10.17487/RFC4601", + } + +@misc{rfc4602, + author="T. Pusateri", + title="{Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis}", + howpublished="RFC 4602 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4602", + pages="1--8", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4602.txt", + key="RFC 4602", + abstract={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.}, + doi="10.17487/RFC4602", + } + +@misc{rfc4603, + author="G. Zorn and G. Weber and R. Foltak", + title="{Additional Values for the NAS-Port-Type Attribute}", + howpublished="RFC 4603 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4603", + pages="1--5", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4603.txt", + key="RFC 4603", + abstract={This document defines a set of values for the NAS-Port-Type RADIUS Attribute. This memo provides information for the Internet community.}, + keywords="radius, Remote Authentication Dial-In User Service", + doi="10.17487/RFC4603", + } + +@misc{rfc4604, + author="H. Holbrook and B. Cain and B. Haberman", + title="{Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast}", + howpublished="RFC 4604 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4604", + pages="1--11", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4604.txt", + key="RFC 4604", + abstract={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]}, + keywords="ssm", + doi="10.17487/RFC4604", + } + +@misc{rfc4605, + author="B. Fenner and H. He and B. Haberman and H. Sandick", + title="{Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding (``IGMP/MLD Proxying'')}", + howpublished="RFC 4605 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4605", + pages="1--12", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4605.txt", + key="RFC 4605", + abstract={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]}, + keywords="", + doi="10.17487/RFC4605", + } + +@misc{rfc4606, + author="E. Mannie and D. Papadimitriou", + title="{Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control}", + howpublished="RFC 4606 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4606", + pages="1--25", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6344", +url="https://www.rfc-editor.org/rfc/rfc4606.txt", + key="RFC 4606", + abstract={This document provides minor clarification to RFC 3946. 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]}, + keywords="", + doi="10.17487/RFC4606", + } + +@misc{rfc4607, + author="H. Holbrook and B. Cain", + title="{Source-Specific Multicast for IP}", + howpublished="RFC 4607 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4607", + pages="1--19", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4607.txt", + key="RFC 4607", + abstract={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]}, + keywords="ipv4, ssm, ipv6", + doi="10.17487/RFC4607", + } + +@misc{rfc4608, + author="D. Meyer and R. Rockell and G. Shepherd", + title="{Source-Specific Protocol Independent Multicast in 232/8}", + howpublished="RFC 4608 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4608", + pages="1--7", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4608.txt", + key="RFC 4608", + abstract={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.}, + keywords="ip, ssm", + doi="10.17487/RFC4608", + } + +@misc{rfc4609, + author="P. Savola and R. Lehtonen and D. Meyer", + title="{Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements}", + howpublished="RFC 4609 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4609", + pages="1--23", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4609.txt", + key="RFC 4609", + abstract={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.}, + keywords="security threats, intra-domain, inter-domain, any-source multicast, asm, source-specific multicast, ssm, embedded rendezvous point, embedded-rp", + doi="10.17487/RFC4609", + } + +@misc{rfc4610, + author="D. Farinacci and Y. Cai", + title="{Anycast-RP Using Protocol Independent Multicast (PIM)}", + howpublished="RFC 4610 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4610", + pages="1--12", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4610.txt", + key="RFC 4610", + abstract={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]}, + keywords="rendezvous point, rp, msdp register, multicast source discovery, register-stop", + doi="10.17487/RFC4610", + } + +@misc{rfc4611, + author="M. McBride and J. Meylor and D. Meyer", + title="{Multicast Source Discovery Protocol (MSDP) Deployment Scenarios}", + howpublished="RFC 4611 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4611", + pages="1--14", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4611.txt", + key="RFC 4611", + abstract={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.}, + keywords="pim-sm, protocol independent multicast sparse mode", + doi="10.17487/RFC4611", + } + +@misc{rfc4612, + author="P. Jones and H. Tamura", + title="{Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration}", + howpublished="RFC 4612 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4612", + pages="1--8", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4612.txt", + key="RFC 4612", + abstract={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.}, + keywords="itu-t recommendation t.38, sdp, session description protocol", + doi="10.17487/RFC4612", + } + +@misc{rfc4613, + author="P. Frojdh and U. Lindgren and M. Westerlund", + title="{Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI)}", + howpublished="RFC 4613 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4613", + pages="1--6", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4613.txt", + key="RFC 4613", + abstract={This document serves to register a media type for Downloadable Sounds. This memo provides information for the Internet community.}, + keywords="dls", + doi="10.17487/RFC4613", + } + +@misc{rfc4614, + author="M. Duke and R. Braden and W. Eddy and E. Blanton", + title="{A Roadmap for Transmission Control Protocol (TCP) Specification Documents}", + howpublished="RFC 4614 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4614", + pages="1--33", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7414, updated by RFC 6247", +url="https://www.rfc-editor.org/rfc/rfc4614.txt", + key="RFC 4614", + abstract={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.}, + doi="10.17487/RFC4614", + } + +@misc{rfc4615, + author="J. Song and R. Poovendran and J. Lee and T. Iwata", + 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)}", + howpublished="RFC 4615 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4615", + pages="1--7", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4615.txt", + key="RFC 4615", + abstract={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]}, + keywords="ipsec, ip security, pseudo-random function", + doi="10.17487/RFC4615", + } + +@misc{rfc4616, + author="K. {Zeilenga (Ed.)}", + title="{The PLAIN Simple Authentication and Security Layer (SASL) Mechanism}", + howpublished="RFC 4616 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4616", + pages="1--11", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4616.txt", + key="RFC 4616", + abstract={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]}, + keywords="data confidentiality", + doi="10.17487/RFC4616", + } + +@misc{rfc4617, + author="J. Kornijenko", + title="{A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project}", + howpublished="RFC 4617 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4617", + pages="1--8", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4617.txt", + key="RFC 4617", + abstract={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.}, + keywords="general contractor, Olimps LTD, subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange Technologies LTD, RIX, Microlink LTD", + doi="10.17487/RFC4617", + } + +@misc{rfc4618, + author="L. Martini and E. Rosen and G. Heron and A. Malis", + title="{Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks}", + howpublished="RFC 4618 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4618", + pages="1--16", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4618.txt", + key="RFC 4618", + abstract={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]}, + keywords="pw, pseudowire, point to point protocol, pdu, packet data unit", + doi="10.17487/RFC4618", + } + +@misc{rfc4619, + author="L. {Martini (Ed.)} and C. {Kawa (Ed.)} and A. {Malis (Ed.)}", + title="{Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks}", + howpublished="RFC 4619 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4619", + pages="1--19", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4619.txt", + key="RFC 4619", + abstract={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]}, + keywords="pseudowire, psn, packet switched network, pw", + doi="10.17487/RFC4619", + } + +@misc{rfc4620, + author="M. Crawford and B. {Haberman (Ed.)}", + title="{IPv6 Node Information Queries}", + howpublished="RFC 4620 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4620", + pages="1--14", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4620.txt", + key="RFC 4620", + abstract={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.}, + keywords="internet protocol version 6", + doi="10.17487/RFC4620", + } + +@misc{rfc4621, + author="T. Kivinen and H. Tschofenig", + title="{Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol}", + howpublished="RFC 4621 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4621", + pages="1--30", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4621.txt", + key="RFC 4621", + abstract={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). 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.}, + keywords="internet key exchange", + doi="10.17487/RFC4621", + } + +@misc{rfc4622, + author="P. Saint-Andre", + title="{Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 4622 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4622", + pages="1--23", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5122", +url="https://www.rfc-editor.org/rfc/rfc4622.txt", + key="RFC 4622", + abstract={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]}, + keywords="Extensible Messaging and Presence Protocol, Internationalized Resource Identifier, Uniform Resource Identifier, Jabber, xmpp, iri, uri", + doi="10.17487/RFC4622", + } + +@misc{rfc4623, + author="A. Malis and M. Townsley", + title="{Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly}", + howpublished="RFC 4623 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4623", + pages="1--17", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4623.txt", + key="RFC 4623", + abstract={This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4623", + } + +@misc{rfc4624, + author="B. Fenner and D. Thaler", + title="{Multicast Source Discovery Protocol (MSDP) MIB}", + howpublished="RFC 4624 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4624", + pages="1--32", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4624.txt", + key="RFC 4624", + abstract={This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers. This memo defines an Experimental Protocol for the Internet community.}, + keywords="management information base, MSDP-MIB", + doi="10.17487/RFC4624", + } + +@misc{rfc4625, + author="C. DeSanti and K. McCloghrie and S. Kode and S. Gai", + title="{Fibre Channel Routing Information MIB}", + howpublished="RFC 4625 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4625", + pages="1--22", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4625.txt", + key="RFC 4625", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. [STANDARDS-TRACK]}, + keywords="management information base, T11-FC-ROUTE-MIB", + doi="10.17487/RFC4625", + } + +@misc{rfc4626, + author="C. DeSanti and V. Gaonkar and K. McCloghrie and S. Gai", + title="{MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol}", + howpublished="RFC 4626 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4626", + pages="1--36", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4626.txt", + key="RFC 4626", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. [STANDARDS-TRACK]}, + keywords="management information base, T11-FC-FSPF-MIB", + doi="10.17487/RFC4626", + } + +@misc{rfc4627, + author="D. Crockford", + title="{The application/json Media Type for JavaScript Object Notation (JSON)}", + howpublished="RFC 4627 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4627", + pages="1--10", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7159", +url="https://www.rfc-editor.org/rfc/rfc4627.txt", + key="RFC 4627", + abstract={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.}, + keywords="data interchange format, ECMAScript Programming Language Standard", + doi="10.17487/RFC4627", + } + +@misc{rfc4628, + author="R. Even", + title="{RTP Payload Format for H.263 Moving RFC 2190 to Historic Status}", + howpublished="RFC 4628 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4628", + pages="1--5", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4628.txt", + key="RFC 4628", + abstract={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.}, + keywords="real-time transport protocol, itu-t, itu telecommunication standardization sector, transfer", + doi="10.17487/RFC4628", + } + +@misc{rfc4629, + author="J. Ott and C. Bormann and G. Sullivan and S. Wenger and R. {Even (Ed.)}", + title="{RTP Payload Format for ITU-T Rec. H.263 Video}", + howpublished="RFC 4629 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4629", + pages="1--29", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4629.txt", + key="RFC 4629", + abstract={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. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec. The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS-TRACK]}, + keywords="real-time transport protocol, multicast, unicast, sdp, session description protocol", + doi="10.17487/RFC4629", + } + +@misc{rfc4630, + author="R. Housley and S. Santesson", + title="{Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}", + howpublished="RFC 4630 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4630", + pages="1--6", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5280", +url="https://www.rfc-editor.org/rfc/rfc4630.txt", + key="RFC 4630", + abstract={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]}, + keywords="utf8string, printablestring", + doi="10.17487/RFC4630", + } + +@misc{rfc4631, + author="M. Dubuc and T. Nadeau and J. Lang and E. McGinnis and A. Farrel", + title="{Link Management Protocol (LMP) Management Information Base (MIB)}", + howpublished="RFC 4631 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4631", + pages="1--83", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4631.txt", + key="RFC 4631", + abstract={This document provides minor corrections to and obsoletes RFC 4327. 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]}, + keywords="lmp-mib", + doi="10.17487/RFC4631", + } + +@misc{rfc4632, + author="V. Fuller and T. Li", + title="{Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan}", + howpublished="RFC 4632 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4632", + pages="1--27", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4632.txt", + key="RFC 4632", + abstract={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.}, + keywords="CIDR-STRA, global routing state", + doi="10.17487/RFC4632", + } + +@misc{rfc4633, + author="S. Hartman", + title="{Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists}", + howpublished="RFC 4633 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4633", + pages="1--7", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4633.txt", + key="RFC 4633", + abstract={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.}, + keywords="", + doi="10.17487/RFC4633", + } + +@misc{rfc4634, + author="D. {Eastlake 3rd} and T. Hansen", + title="{US Secure Hash Algorithms (SHA and HMAC-SHA)}", + howpublished="RFC 4634 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4634", + pages="1--108", + year=2006, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6234", +url="https://www.rfc-editor.org/rfc/rfc4634.txt", + key="RFC 4634", + abstract={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. Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.}, + keywords="fips, federal information processing standard, sha-224, sha-256, sha-384, sha-512", + doi="10.17487/RFC4634", + } + +@misc{rfc4635, + author="D. {Eastlake 3rd}", + title="{HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers}", + howpublished="RFC 4635 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4635", + pages="1--8", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4635.txt", + key="RFC 4635", + abstract={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]}, + keywords="dns, resource record, rr, cryptographic message authentication code, cmac", + doi="10.17487/RFC4635", + } + +@misc{rfc4636, + author="C. Perkins", + title="{Foreign Agent Error Extension for Mobile IPv4}", + howpublished="RFC 4636 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4636", + pages="1--6", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4636.txt", + key="RFC 4636", + abstract={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]}, + keywords="internet protocol", + doi="10.17487/RFC4636", + } + +@misc{rfc4638, + author="P. Arberg and D. Kourkouzelis and M. Duckett and T. Anschutz and J. Moisand", + title="{Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)}", + howpublished="RFC 4638 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4638", + pages="1--9", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4638.txt", + key="RFC 4638", + abstract={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.}, + doi="10.17487/RFC4638", + } + +@misc{rfc4639, + author="R. Woundy and K. Marez", + title="{Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems}", + howpublished="RFC 4639 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4639", + pages="1--88", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4639.txt", + key="RFC 4639", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems. This memo obsoletes RFC 2669. [STANDARDS-TRACK]}, + keywords="snmp, simple network management protocol", + doi="10.17487/RFC4639", + } + +@misc{rfc4640, + author="A. {Patel (Ed.)} and G. {Giaretta (Ed.)}", + title="{Problem Statement for bootstrapping Mobile IPv6 (MIPv6)}", + howpublished="RFC 4640 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4640", + pages="1--22", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4640.txt", + key="RFC 4640", + abstract={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.}, + keywords="internet protocol version 6, mobile node", + doi="10.17487/RFC4640", + } + +@misc{rfc4641, + author="O. Kolkman and R. Gieben", + title="{DNSSEC Operational Practices}", + howpublished="RFC 4641 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4641", + pages="1--35", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6781", +url="https://www.rfc-editor.org/rfc/rfc4641.txt", + key="RFC 4641", + abstract={This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. 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. 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.}, + keywords="dns, domain name space, security extensions, zone administrator, DNS-SOC, cryptology, resource records, rrs", + doi="10.17487/RFC4641", + } + +@misc{rfc4642, + author="K. Murchison and J. Vinocur and C. Newman", + title="{Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)}", + howpublished="RFC 4642 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4642", + pages="1--14", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8143", +url="https://www.rfc-editor.org/rfc/rfc4642.txt", + key="RFC 4642", + abstract={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]}, + keywords="encryption, single link confidentiality", + doi="10.17487/RFC4642", + } + +@misc{rfc4643, + author="J. Vinocur and K. Murchison", + title="{Network News Transfer Protocol (NNTP) Extension for Authentication}", + howpublished="RFC 4643 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4643", + pages="1--24", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4643.txt", + key="RFC 4643", + abstract={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. 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]}, + keywords="authinfo user/pass, authinfo simple, authinfo generic, sasl, simple authentication and security layer", + doi="10.17487/RFC4643", + } + +@misc{rfc4644, + author="J. Vinocur and K. Murchison", + title="{Network News Transfer Protocol (NNTP) Extension for Streaming Feeds}", + howpublished="RFC 4644 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4644", + pages="1--14", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4644.txt", + key="RFC 4644", + abstract={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. This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]}, + keywords="check, takethis, mode stream", + doi="10.17487/RFC4644", + } + +@misc{rfc4645, + author="D. Ewell", + title="{Initial Language Subtag Registry}", + howpublished="RFC 4645 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4645", + pages="1--7", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4645.txt", + key="RFC 4645", + abstract={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.}, + keywords="iana", + doi="10.17487/RFC4645", + } + +@misc{rfc4646, + author="A. Phillips and M. Davis", + title="{Tags for Identifying Languages}", + howpublished="RFC 4646 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4646", + pages="1--59", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5646", +url="https://www.rfc-editor.org/rfc/rfc4646.txt", + key="RFC 4646", + abstract={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.}, + keywords="Lang-Tag", + doi="10.17487/RFC4646", + } + +@misc{rfc4647, + author="A. Phillips and M. Davis", + title="{Matching of Language Tags}", + howpublished="RFC 4647 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4647", + pages="1--20", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4647.txt", + key="RFC 4647", + abstract={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.}, + keywords="Lang-Tag", + doi="10.17487/RFC4647", + } + +@misc{rfc4648, + author="S. Josefsson", + title="{The Base16, Base32, and Base64 Data Encodings}", + howpublished="RFC 4648 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4648", + pages="1--18", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4648.txt", + key="RFC 4648", + abstract={This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]}, + keywords="schemes, data, line-feeds, alphabets, base encoding, hex", + doi="10.17487/RFC4648", + } + +@misc{rfc4649, + author="B. Volz", + title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option}", + howpublished="RFC 4649 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4649", + pages="1--6", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4649.txt", + key="RFC 4649", + abstract={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]}, + keywords="", + doi="10.17487/RFC4649", + } + +@misc{rfc4650, + author="M. Euchner", + title="{HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)}", + howpublished="RFC 4650 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4650", + pages="1--27", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4650.txt", + key="RFC 4650", + abstract={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]}, + keywords="Multicast security, MIKEY, key management, Diffie-Hellman, key agreement, HMAC", + doi="10.17487/RFC4650", + } + +@misc{rfc4651, + author="C. Vogt and J. Arkko", + title="{A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization}", + howpublished="RFC 4651 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4651", + pages="1--31", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4651.txt", + key="RFC 4651", + abstract={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.}, + keywords="Mobile IPv6, Route Optimization, Enhancement, Mobility, Handoff, IP Address Tests, Protected Tunnels, Optimistic Behavior, Proactive IP Address Tests, Concurrent Care-of Address Tests, Diverted Routing, Credit-Based Authorization, Heuristic Monitoring, Crypto-Based Identifiers, Pre-Configuration, Semi-Permanent Security Associations, Delegation, Mobile Networks, Location Privacy", + doi="10.17487/RFC4651", + } + +@misc{rfc4652, + author="D. {Papadimitriou (Ed.)} and L.Ong and J. Sadler and S. Shew and D. Ward", + title="{Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements}", + howpublished="RFC 4652 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4652", + pages="1--22", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4652.txt", + key="RFC 4652", + abstract={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). 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.}, + keywords="gmpls, generalized multiprotocol label switching, otn, optical transport networks, sonet, sdh, synchronous optical network, synchronous digital hierarchy, itu-t", + doi="10.17487/RFC4652", + } + +@misc{rfc4653, + author="S. Bhandarkar and A. L. N. Reddy and M. Allman and E. Blanton", + title="{Improving the Robustness of TCP to Non-Congestion Events}", + howpublished="RFC 4653 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4653", + pages="1--18", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4653.txt", + key="RFC 4653", + abstract={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.}, + keywords="ncr, non-congestion robustness, transmission control protocol", + doi="10.17487/RFC4653", + } + +@misc{rfc4654, + author="J. Widmer and M. Handley", + title="{TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification}", + howpublished="RFC 4654 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4654", + pages="1--32", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4654.txt", + key="RFC 4654", + abstract={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.}, + keywords="streaming media, multicase, ip, internet protocol", + doi="10.17487/RFC4654", + } + +@misc{rfc4655, + author="A. Farrel and J.-P. Vasseur and J. Ash", + title="{A Path Computation Element (PCE)-Based Architecture}", + howpublished="RFC 4655 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4655", + pages="1--40", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4655.txt", + key="RFC 4655", + abstract={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. 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.}, + keywords="traffic engineering", + doi="10.17487/RFC4655", + } + +@misc{rfc4656, + author="S. Shalunov and B. Teitelbaum and A. Karp and J. Boote and M. Zekauskas", + title="{A One-way Active Measurement Protocol (OWAMP)}", + howpublished="RFC 4656 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4656", + pages="1--56", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7717, 7718", +url="https://www.rfc-editor.org/rfc/rfc4656.txt", + key="RFC 4656", + abstract={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]}, + keywords="unidirectional characteristics, one-way, gps, cdma", + doi="10.17487/RFC4656", + } + +@misc{rfc4657, + author="J. {Ash (Ed.)} and J.L. Le {Roux (Ed.)}", + title="{Path Computation Element (PCE) Communication Protocol Generic Requirements}", + howpublished="RFC 4657 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4657", + pages="1--21", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4657.txt", + key="RFC 4657", + abstract={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.}, + keywords="pce architecture, pcc, path computation client", + doi="10.17487/RFC4657", + } + +@misc{rfc4659, + author="J. De Clercq and D. Ooms and M. Carugi and F. Le Faucheur", + title="{BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN}", + howpublished="RFC 4659 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4659", + pages="1--18", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4659.txt", + key="RFC 4659", + abstract={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''. 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]}, + keywords="service provider, border gateway protocol, multiprotocol label switching", + doi="10.17487/RFC4659", + } + +@misc{rfc4660, + author="H. Khartabil and E. Leppanen and M. Lonnfors and J. Costa-Requena", + title="{Functional Description of Event Notification Filtering}", + howpublished="RFC 4660 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4660", + pages="1--31", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6665", +url="https://www.rfc-editor.org/rfc/rfc4660.txt", + key="RFC 4660", + abstract={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. 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]}, + keywords="event state subscription, presence, filter criteria", + doi="10.17487/RFC4660", + } + +@misc{rfc4661, + author="H. Khartabil and E. Leppanen and M. Lonnfors and J. Costa-Requena", + title="{An Extensible Markup Language (XML)-Based Format for Event Notification Filtering}", + howpublished="RFC 4661 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4661", + pages="1--24", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4661.txt", + key="RFC 4661", + abstract={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]}, + keywords="event state subscription, presence, filter criteria", + doi="10.17487/RFC4661", + } + +@misc{rfc4662, + author="A. B. Roach and B. Campbell and J. Rosenberg", + title="{A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists}", + howpublished="RFC 4662 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4662", + pages="1--39", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4662.txt", + key="RFC 4662", + abstract={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]}, + keywords="", + doi="10.17487/RFC4662", + } + +@misc{rfc4663, + author="D. Harrington", + title="{Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG}", + howpublished="RFC 4663 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4663", + pages="1--22", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4663.txt", + key="RFC 4663", + abstract={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.}, + keywords="management information base", + doi="10.17487/RFC4663", + } + +@misc{rfc4664, + author="L. {Andersson (Ed.)} and E. {Rosen (Ed.)}", + title="{Framework for Layer 2 Virtual Private Networks (L2VPNs)}", + howpublished="RFC 4664 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4664", + pages="1--44", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4664.txt", + key="RFC 4664", + abstract={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.}, + doi="10.17487/RFC4664", + } + +@misc{rfc4665, + author="W. {Augustyn (Ed.)} and Y. {Serbest (Ed.)}", + title="{Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks}", + howpublished="RFC 4665 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4665", + pages="1--32", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4665.txt", + key="RFC 4665", + abstract={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.}, + keywords="l2vpn, ppvpn, virtual private wire service, vpws, virtual private lan service, vpls", + doi="10.17487/RFC4665", + } + +@misc{rfc4666, + author="K. {Morneault (Ed.)} and J. {Pastor-Balbas (Ed.)}", + title="{Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)}", + howpublished="RFC 4666 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4666", + pages="1--124", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4666.txt", + key="RFC 4666", + abstract={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]}, + keywords="mtp, isup, sccp, sctp, stream control tranmission protocol, mgc, media gateway protocol, st, signalling gateway", + doi="10.17487/RFC4666", + } + +@misc{rfc4667, + author="W. Luo", + title="{Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)}", + howpublished="RFC 4667 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4667", + pages="1--15", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4667.txt", + key="RFC 4667", + abstract={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]}, + keywords="L2VPN, L2TP, L2TPv3, pseudowire, forwarder", + doi="10.17487/RFC4667", + } + +@misc{rfc4668, + author="D. Nelson", + title="{RADIUS Authentication Client MIB for IPv6}", + howpublished="RFC 4668 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4668", + pages="1--24", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4668.txt", + key="RFC 4668", + abstract={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. 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]}, + keywords="management information base, security, remote access dialin user service, RADIUS-AUTH-CLIENT-MIB", + doi="10.17487/RFC4668", + } + +@misc{rfc4669, + author="D. Nelson", + title="{RADIUS Authentication Server MIB for IPv6}", + howpublished="RFC 4669 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4669", + pages="1--25", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4669.txt", + key="RFC 4669", + abstract={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. 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]}, + keywords="management information base, security, remote access dialin user service, RADIUS-AUTH-SERVER-MIB", + doi="10.17487/RFC4669", + } + +@misc{rfc4670, + author="D. Nelson", + title="{RADIUS Accounting Client MIB for IPv6}", + howpublished="RFC 4670 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4670", + pages="1--23", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4670.txt", + key="RFC 4670", + abstract={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. 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.}, + keywords="management information base, security, remote access dialin user service, RADIUS-ACC-CLIENT-MIB", + doi="10.17487/RFC4670", + } + +@misc{rfc4671, + author="D. Nelson", + title="{RADIUS Accounting Server MIB for IPv6}", + howpublished="RFC 4671 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4671", + pages="1--24", + year=2006, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4671.txt", + key="RFC 4671", + abstract={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. 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.}, + keywords="management information base, security, remote access dialin user service, RADIUS-ACC-SERVER-MIB", + doi="10.17487/RFC4671", + } + +@misc{rfc4672, + author="S. De Cnodder and N. Jonnala and M. Chiba", + title="{RADIUS Dynamic Authorization Client MIB}", + howpublished="RFC 4672 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4672", + pages="1--24", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4672.txt", + key="RFC 4672", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes 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.}, + keywords="remote authentication dial-in user service, dac, dynamic authorization client, RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS, management information base", + doi="10.17487/RFC4672", + } + +@misc{rfc4673, + author="S. De Cnodder and N. Jonnala and M. Chiba", + title="{RADIUS Dynamic Authorization Server MIB}", + howpublished="RFC 4673 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4673", + pages="1--24", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4673.txt", + key="RFC 4673", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes 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.}, + keywords="management information base, remote authentication dial-in user service, RADIUS-DYNAUTH-SERVER-MIB", + doi="10.17487/RFC4673", + } + +@misc{rfc4674, + author="J.L. Le {Roux (Ed.)}", + title="{Requirements for Path Computation Element (PCE) Discovery}", + howpublished="RFC 4674 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4674", + pages="1--19", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4674.txt", + key="RFC 4674", + abstract={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.}, + keywords="path computation client, pcc", + doi="10.17487/RFC4674", + } + +@misc{rfc4675, + author="P. Congdon and M. Sanchez and B. Aboba", + title="{RADIUS Attributes for Virtual LAN and Priority Support}", + howpublished="RFC 4675 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4675", + pages="1--15", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4675.txt", + key="RFC 4675", + abstract={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]}, + keywords="remote authentication dial-in user service, local area network", + doi="10.17487/RFC4675", + } + +@misc{rfc4676, + author="H. Schulzrinne", + title="{Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information}", + howpublished="RFC 4676 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4676", + pages="1--19", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4776", +url="https://www.rfc-editor.org/rfc/rfc4676.txt", + key="RFC 4676", + abstract={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]}, + keywords="lci, local configuration information", + doi="10.17487/RFC4676", + } + +@misc{rfc4677, + author="P. Hoffman and S. Harris", + title="{The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force}", + howpublished="RFC 4677 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4677", + pages="1--50", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6722", +url="https://www.rfc-editor.org/rfc/rfc4677.txt", + key="RFC 4677", + abstract={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.}, + keywords="meeting", + doi="10.17487/RFC4677", + } + +@misc{rfc4678, + author="A. Bivens", + title="{Server/Application State Protocol v1}", + howpublished="RFC 4678 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4678", + pages="1--48", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4678.txt", + key="RFC 4678", + abstract={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.}, + keywords="sasp, server/application state protocol", + doi="10.17487/RFC4678", + } + +@misc{rfc4679, + author="V. Mammoliti and G. Zorn and P. Arberg and R. Rennison", + title="{DSL Forum Vendor-Specific RADIUS Attributes}", + howpublished="RFC 4679 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4679", + pages="1--25", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4679.txt", + key="RFC 4679", + abstract={This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum. 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.}, + keywords="remote authentication dial-in user service, vsa, dsl, digital subscriber line", + doi="10.17487/RFC4679", + } + +@misc{rfc4680, + author="S. Santesson", + title="{TLS Handshake Message for Supplemental Data}", + howpublished="RFC 4680 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4680", + pages="1--9", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8447", +url="https://www.rfc-editor.org/rfc/rfc4680.txt", + key="RFC 4680", + abstract={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]}, + keywords="transport layer security", + doi="10.17487/RFC4680", + } + +@misc{rfc4681, + author="S. Santesson and A. Medvinsky and J. Ball", + title="{TLS User Mapping Extension}", + howpublished="RFC 4681 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4681", + pages="1--11", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4681.txt", + key="RFC 4681", + abstract={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]}, + keywords="transport layer security, handshake message, upndomainhint", + doi="10.17487/RFC4681", + } + +@misc{rfc4682, + author="E. Nechamkin and J-F. Mule", + title="{Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices}", + howpublished="RFC 4682 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4682", + pages="1--60", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4682.txt", + key="RFC 4682", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]}, + keywords="mib, snmp, simple network management protocol, PKTC-IETF-MTA-MIB", + doi="10.17487/RFC4682", + } + +@misc{rfc4683, + author="J. Park and J. Lee and H.. Lee and S. Park and T. Polk", + title="{Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)}", + howpublished="RFC 4683 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4683", + pages="1--20", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4683.txt", + key="RFC 4683", + abstract={This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate. 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]}, + keywords="subjectaltname, privacy-sensitive, identifiers, pepsi", + doi="10.17487/RFC4683", + } + +@misc{rfc4684, + author="P. Marques and R. Bonica and L. Fang and L. Martini and R. Raszuk and K. Patel and J. Guichard", + title="{Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)}", + howpublished="RFC 4684 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4684", + pages="1--14", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4684.txt", + key="RFC 4684", + abstract={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]}, + keywords="mp-bgp, bgp speakers, route target", + doi="10.17487/RFC4684", + } + +@misc{rfc4685, + author="J. Snell", + title="{Atom Threading Extensions}", + howpublished="RFC 4685 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4685", + pages="1--12", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4685.txt", + key="RFC 4685", + abstract={This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. [STANDARDS-TRACK]}, + keywords="atom syndication format, extension, threading, syndication", + doi="10.17487/RFC4685", + } + +@misc{rfc4686, + author="J. Fenton", + title="{Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)}", + howpublished="RFC 4686 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4686", + pages="1--29", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4686.txt", + key="RFC 4686", + abstract={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.}, + keywords="email, attack, authentication, signature, ssp", + doi="10.17487/RFC4686", + } + +@misc{rfc4687, + author="S. Yasukawa and A. Farrel and D. King and T. Nadeau", + title="{Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks}", + howpublished="RFC 4687 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4687", + pages="1--14", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4687.txt", + key="RFC 4687", + abstract={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. 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. 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.}, + keywords="multiprotocol label switching, pwmp, lsp, p2mp mpls lsp", + doi="10.17487/RFC4687", + } + +@misc{rfc4688, + author="S. Rushing", + title="{A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D}", + howpublished="RFC 4688 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4688", + pages="1--8", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4688.txt", + key="RFC 4688", + abstract={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.}, + doi="10.17487/RFC4688", + } + +@misc{rfc4689, + author="S. Poretsky and J. Perser and S. Erramilli and S. Khurana", + title="{Terminology for Benchmarking Network-layer Traffic Control Mechanisms}", + howpublished="RFC 4689 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4689", + pages="1--34", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4689.txt", + key="RFC 4689", + abstract={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.}, + keywords="packet classification", + doi="10.17487/RFC4689", + } + +@misc{rfc4690, + author="J. Klensin and P. Faltstrom and C. Karp and IAB", + title="{Review and Recommendations for Internationalized Domain Names (IDNs)}", + howpublished="RFC 4690 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4690", + pages="1--37", + year=2006, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4690.txt", + key="RFC 4690", + abstract={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.}, + keywords="dns, domain namespace, idna, internationalizing domain names in applications", + doi="10.17487/RFC4690", + } + +@misc{rfc4691, + author="L. {Andersson (Ed.)}", + title="{Guidelines for Acting as an IETF Liaison to Another Organization}", + howpublished="RFC 4691 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4691", + pages="1--14", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4691.txt", + key="RFC 4691", + abstract={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.}, + keywords="internet engineering task force, sdo, standards development organization, consortium, industrial forum", + doi="10.17487/RFC4691", + } + +@misc{rfc4692, + author="G. Huston", + title="{Considerations on the IPv6 Host Density Metric}", + howpublished="RFC 4692 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4692", + pages="1--17", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4692.txt", + key="RFC 4692", + abstract={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.}, + keywords="internet protocol version 6, ipv6 unicast address blocks", + doi="10.17487/RFC4692", + } + +@misc{rfc4693, + author="H. Alvestrand", + title="{IETF Operational Notes}", + howpublished="RFC 4693 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4693", + pages="1--10", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6393", +url="https://www.rfc-editor.org/rfc/rfc4693.txt", + key="RFC 4693", + abstract={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. It proposes to establish this series as an RFC 3933 process experiment. This memo defines an Experimental Protocol for the Internet community.}, + keywords="ION", + doi="10.17487/RFC4693", + } + +@misc{rfc4694, + author="J. Yu", + title="{Number Portability Parameters for the ``tel'' URI}", + howpublished="RFC 4694 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4694", + pages="1--15", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4694.txt", + key="RFC 4694", + abstract={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]}, + keywords="uniform resource identifier, np", + doi="10.17487/RFC4694", + } + +@misc{rfc4695, + author="J. Lazzaro and J. Wawrzynek", + title="{RTP Payload Format for MIDI}", + howpublished="RFC 4695 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4695", + pages="1--169", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6295", +url="https://www.rfc-editor.org/rfc/rfc4695.txt", + key="RFC 4695", + abstract={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]}, + keywords="asc, content streaming, DLS 2, General MIDI, MIDI, MIDI file, MIDI file streaming, MIDI light control, MIDI rendering, MIDI ringtone, MIDI streaming MIDI sequencer, MIDI time code, MIDI timecode, MIDI Manufacturers Association, MMA mpeg4-generic MPEG 4, MPEG 4 Structured Audio, MPEG 4 Synthetic Coding, MTC, musical notes, network musical performance, recovery journal, Show Control, sonification, ringtone, rtp-midi, RTP, RTP MIDI, SMPTE time code, SMPTE timecode, Standard MIDI Files, XMF", + doi="10.17487/RFC4695", + } + +@misc{rfc4696, + author="J. Lazzaro and J. Wawrzynek", + title="{An Implementation Guide for RTP MIDI}", + howpublished="RFC 4696 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4696", + pages="1--38", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4696.txt", + key="RFC 4696", + abstract={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]}, + keywords="checkpoint packet, checkpoint history, guard packets, jitter, keep-alive packets, MIDI, musical telepresence, network musical performance, NMP, receiving algorithm, recovery journal, recovery journal receiving structure, recovery journal sending structure, RTP, RTP MIDI, queuing MIDI, sending algorithm, sending MIDI, telepresence", + doi="10.17487/RFC4696", + } + +@misc{rfc4697, + author="M. Larson and P. Barber", + title="{Observed DNS Resolution Misbehavior}", + howpublished="RFC 4697 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4697", + pages="1--18", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4697.txt", + key="RFC 4697", + abstract={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.}, + keywords="domain name system, tld, top level domain", + doi="10.17487/RFC4697", + } + +@misc{rfc4698, + author="E. Gunduz and A. Newton and S. Kerr", + title="{IRIS: An Address Registry (areg) Type for the Internet Registry Information Service}", + howpublished="RFC 4698 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4698", + pages="1--48", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4698.txt", + key="RFC 4698", + abstract={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]}, + keywords="ip address, autonomous system number, internet protocol address", + doi="10.17487/RFC4698", + } + +@misc{rfc4701, + author="M. Stapp and T. Lemon and A. Gustafsson", + title="{A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)}", + howpublished="RFC 4701 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4701", + pages="1--12", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5494", +url="https://www.rfc-editor.org/rfc/rfc4701.txt", + key="RFC 4701", + abstract={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]}, + keywords="dns fqdn, fully qualified domain name", + doi="10.17487/RFC4701", + } + +@misc{rfc4702, + author="M. Stapp and B. Volz and Y. Rekhter", + title="{The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option}", + howpublished="RFC 4702 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4702", + pages="1--17", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4702.txt", + key="RFC 4702", + abstract={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]}, + keywords="dhcpv4, dns rr", + doi="10.17487/RFC4702", + } + +@misc{rfc4703, + author="M. Stapp and B. Volz", + title="{Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients}", + howpublished="RFC 4703 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4703", + pages="1--13", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4703.txt", + key="RFC 4703", + abstract={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]}, + keywords="dynamic assignment, dns, dhcid dns rr", + doi="10.17487/RFC4703", + } + +@misc{rfc4704, + author="B. Volz", + title="{The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option}", + howpublished="RFC 4704 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4704", + pages="1--15", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4704.txt", + key="RFC 4704", + abstract={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]}, + keywords="dns rr", + doi="10.17487/RFC4704", + } + +@misc{rfc4705, + author="R. Housley and A. Corry", + title="{GigaBeam High-Speed Radio Link Encryption}", + howpublished="RFC 4705 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4705", + pages="1--15", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4705.txt", + key="RFC 4705", + abstract={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.}, + keywords="key management, wifiber, radio link", + doi="10.17487/RFC4705", + } + +@misc{rfc4706, + author="M. Morgenstern and M. Dodge and S. Baillie and U. Bonollo", + title="{Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)}", + howpublished="RFC 4706 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4706", + pages="1--167", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4706.txt", + key="RFC 4706", + abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the ``Asymmetric Digital Subscriber Line'' family of interface types: ADSL, ADSL2, ADSL2+, and their variants. [STANDARDS-TRACK]}, + keywords="mib, management information base, adsl2+, ADSL2-LINE-TC-MIB, ADSL2-LINE-MIB", + doi="10.17487/RFC4706", + } + +@misc{rfc4707, + author="P. Grau and V. Heinau and H. Schlichting and R. Schuettler", + title="{Netnews Administration System (NAS)}", + howpublished="RFC 4707 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4707", + pages="1--49", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4707.txt", + key="RFC 4707", + abstract={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. 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. 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.}, + keywords="news servers, news administrator, news reader", + doi="10.17487/RFC4707", + } + +@misc{rfc4708, + author="A. Miller", + title="{CellML Media Type}", + howpublished="RFC 4708 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4708", + pages="1--7", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4708.txt", + key="RFC 4708", + abstract={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.}, + keywords="media format, mathematical model, mathematical modelling, mathematical modeling, content MathML, markup languages, bioengineering, biology", + doi="10.17487/RFC4708", + } + +@misc{rfc4709, + author="J. Reschke", + title="{Mounting Web Distributed Authoring and Versioning (WebDAV) Servers}", + howpublished="RFC 4709 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4709", + pages="1--15", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4709.txt", + key="RFC 4709", + abstract={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. 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.}, + keywords="drag-and-drop", + doi="10.17487/RFC4709", + } + +@misc{rfc4710, + author="A. Siddiqui and D. Romascanu and E. Golovinsky", + title="{Real-time Application Quality-of-Service Monitoring (RAQMON) Framework}", + howpublished="RFC 4710 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4710", + pages="1--36", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4710.txt", + key="RFC 4710", + abstract={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]}, + keywords="internet protocol, end-devices, qos, quality of service, snmp, simple network management protocol", + doi="10.17487/RFC4710", + } + +@misc{rfc4711, + author="A. Siddiqui and D. Romascanu and E. Golovinsky", + title="{Real-time Application Quality-of-Service Monitoring (RAQMON) MIB}", + howpublished="RFC 4711 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4711", + pages="1--38", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4711.txt", + key="RFC 4711", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB, RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. [STANDARDS-TRACK]}, + keywords="management information base, remote monitoring mib, qos, RAQMON-MIB", + doi="10.17487/RFC4711", + } + +@misc{rfc4712, + author="A. Siddiqui and D. Romascanu and E. Golovinsky and M. Rahman and Y. Kim", + title="{Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)}", + howpublished="RFC 4712 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4712", + pages="1--48", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4712.txt", + key="RFC 4712", + abstract={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]}, + keywords="mib, management information base, snmp, simple network management protocol, rds, raqmon data source, qos, RAQMON-RDS-MIB", + doi="10.17487/RFC4712", + } + +@misc{rfc4713, + author="X. Lee and W. Mao and E. Chen and N. Hsu and J. Klensin", + title="{Registration and Administration Recommendations for Chinese Domain Names}", + howpublished="RFC 4713 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4713", + pages="1--9", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4713.txt", + key="RFC 4713", + abstract={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.}, + keywords="cdn, sc, simplified chinese, tc, traditional chinese", + doi="10.17487/RFC4713", + } + +@misc{rfc4714, + author="A. Mankin and S. Hayes", + title="{Requirements for IETF Technical Publication Service}", + howpublished="RFC 4714 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4714", + pages="1--24", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4714.txt", + key="RFC 4714", + abstract={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.}, + keywords="internet engineering task force", + doi="10.17487/RFC4714", + } + +@misc{rfc4715, + author="M. Munakata and S. Schubert and T. Ohba", + title="{The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI}", + howpublished="RFC 4715 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4715", + pages="1--14", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4715.txt", + key="RFC 4715", + abstract={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.}, + keywords="uniform resource identifier, isup, isdn user part", + doi="10.17487/RFC4715", + } + +@misc{rfc4716, + author="J. Galbraith and R. Thayer", + title="{The Secure Shell (SSH) Public Key File Format}", + howpublished="RFC 4716 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4716", + pages="1--10", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4716.txt", + key="RFC 4716", + abstract={This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.}, + doi="10.17487/RFC4716", + } + +@misc{rfc4717, + author="L. Martini and J. Jayakumar and M. Bocci and N. El-Aawar and J. Brayley and G. Koleyni", + title="{Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks}", + howpublished="RFC 4717 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4717", + pages="1--40", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4717.txt", + key="RFC 4717", + abstract={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]}, + keywords="pw, pseudowire, multiprotocol label switching", + doi="10.17487/RFC4717", + } + +@misc{rfc4718, + author="P. Eronen and P. Hoffman", + title="{IKEv2 Clarifications and Implementation Guidelines}", + howpublished="RFC 4718 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4718", + pages="1--58", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5996", +url="https://www.rfc-editor.org/rfc/rfc4718.txt", + key="RFC 4718", + abstract={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.}, + keywords="internet key exchange", + doi="10.17487/RFC4718", + } + +@misc{rfc4719, + author="R. {Aggarwal (Ed.)} and M. {Townsley (Ed.)} and M. Dos {Santos (Ed.)}", + title="{Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)}", + howpublished="RFC 4719 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4719", + pages="1--14", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5641", +url="https://www.rfc-editor.org/rfc/rfc4719.txt", + key="RFC 4719", + abstract={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]}, + keywords="port-to-port, vlan", + doi="10.17487/RFC4719", + } + +@misc{rfc4720, + author="A. Malis and D. Allan and N. Del Regno", + title="{Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention}", + howpublished="RFC 4720 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4720", + pages="1--9", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4720.txt", + key="RFC 4720", + abstract={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]}, + keywords="fcs", + doi="10.17487/RFC4720", + } + +@misc{rfc4721, + author="C. Perkins and P. Calhoun and J. Bharatia", + title="{Mobile IPv4 Challenge/Response Extensions (Revised)}", + howpublished="RFC 4721 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4721", + pages="1--26", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4721.txt", + key="RFC 4721", + abstract={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. 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. 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 avail able 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]}, + keywords="chap", + doi="10.17487/RFC4721", + } + +@misc{rfc4722, + author="J. Van Dyke and E. {Burger (Ed.)} and A. Spitzer", + title="{Media Server Control Markup Language (MSCML) and Protocol}", + howpublished="RFC 4722 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4722", + pages="1--81", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5022", +url="https://www.rfc-editor.org/rfc/rfc4722.txt", + key="RFC 4722", + abstract={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.}, + keywords="sip, ivr, interactive voice response", + doi="10.17487/RFC4722", + } + +@misc{rfc4723, + author="T. Kosonen and T. White", + title="{Registration of Media Type audio/mobile-xmf}", + howpublished="RFC 4723 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4723", + pages="1--8", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4723.txt", + key="RFC 4723", + abstract={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.}, + keywords="mma, midi manufacturers association, association of musical electronices industry, amei, MIDI, Musical Instrument Digital Interface", + doi="10.17487/RFC4723", + } + +@misc{rfc4724, + author="S. Sangli and E. Chen and R. Fernando and J. Scudder and Y. Rekhter", + title="{Graceful Restart Mechanism for BGP}", + howpublished="RFC 4724 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4724", + pages="1--15", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4724.txt", + key="RFC 4724", + abstract={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. 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]}, + keywords="border gateway protocol, end-of-rib, bgp restart", + doi="10.17487/RFC4724", + } + +@misc{rfc4725, + author="A. Mayrhofer and B. Hoeneisen", + title="{ENUM Validation Architecture}", + howpublished="RFC 4725 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4725", + pages="1--17", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4725.txt", + key="RFC 4725", + abstract={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.}, + keywords="E.164, Registry, Registrar, Registrant, Assignee", + doi="10.17487/RFC4725", + } + +@misc{rfc4726, + author="A. Farrel and J.-P. Vasseur and A. Ayyangar", + title="{A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering}", + howpublished="RFC 4726 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4726", + pages="1--22", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4726.txt", + key="RFC 4726", + abstract={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. 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.}, + keywords="mpls, mpls-te, te, lsp, label switched path", + doi="10.17487/RFC4726", + } + +@misc{rfc4727, + author="B. Fenner", + title="{Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers}", + howpublished="RFC 4727 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4727", + pages="1--11", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4727.txt", + key="RFC 4727", + abstract={When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. 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]}, + keywords="", + doi="10.17487/RFC4727", + } + +@misc{rfc4728, + author="D. Johnson and Y. Hu and D. Maltz", + title="{The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4}", + howpublished="RFC 4728 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4728", + pages="1--107", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4728.txt", + key="RFC 4728", + abstract={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 prot ocol 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.}, + keywords="route discovery, route maintenance", + doi="10.17487/RFC4728", + } + +@misc{rfc4729, + author="M. Abel", + title="{A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum}", + howpublished="RFC 4729 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4729", + pages="1--7", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4729.txt", + key="RFC 4729", + abstract={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.}, + keywords="forum technical committee", + doi="10.17487/RFC4729", + } + +@misc{rfc4730, + author="E. Burger and M. Dolly", + title="{A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)}", + howpublished="RFC 4730 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4730", + pages="1--56", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4730.txt", + key="RFC 4730", + abstract={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]}, + keywords="ua, user agent, dtmf, dual tone multi-frequency", + doi="10.17487/RFC4730", + } + +@misc{rfc4731, + author="A. Melnikov and D. Cridland", + title="{IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned}", + howpublished="RFC 4731 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4731", + pages="1--6", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4731.txt", + key="RFC 4731", + abstract={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]}, + keywords="uid search, uid", + doi="10.17487/RFC4731", + } + +@misc{rfc4732, + author="M. {Handley (Ed.)} and E. {Rescorla (Ed.)} and IAB", + title="{Internet Denial-of-Service Considerations}", + howpublished="RFC 4732 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4732", + pages="1--38", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4732.txt", + key="RFC 4732", + abstract={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.}, + keywords="dos", + doi="10.17487/RFC4732", + } + +@misc{rfc4733, + author="H. Schulzrinne and T. Taylor", + title="{RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals}", + howpublished="RFC 4733 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4733", + pages="1--49", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4734, 5244", +url="https://www.rfc-editor.org/rfc/rfc4733.txt", + key="RFC 4733", + abstract={This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833. 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. 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]}, + keywords="real-time, application, protocol, DTMF, dual-tone, multifrequency", + doi="10.17487/RFC4733", + } + +@misc{rfc4734, + author="H. Schulzrinne and T. Taylor", + title="{Definition of Events for Modem, Fax, and Text Telephony Signals}", + howpublished="RFC 4734 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4734", + pages="1--47", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4734.txt", + key="RFC 4734", + abstract={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]}, + keywords="real-time, application, protocol, DTMF, dual-tone, multifrequency", + doi="10.17487/RFC4734", + } + +@misc{rfc4735, + author="T. Taylor", + title="{Example Media Types for Use in Documentation}", + howpublished="RFC 4735 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4735", + pages="1--6", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4735.txt", + key="RFC 4735", + abstract={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]}, + keywords="media type, example", + doi="10.17487/RFC4735", + } + +@misc{rfc4736, + author="JP. {Vasseur (Ed.)} and Y. Ikejiri and R. Zhang", + title="{Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)}", + howpublished="RFC 4736 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4736", + pages="1--14", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4736.txt", + key="RFC 4736", + abstract={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.}, + keywords="rsvp-te, te lsp path", + doi="10.17487/RFC4736", + } + +@misc{rfc4737, + author="A. Morton and L. Ciavattone and G. Ramachandran and S. Shalunov and J. Perser", + title="{Packet Reordering Metrics}", + howpublished="RFC 4737 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4737", + pages="1--45", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6248", +url="https://www.rfc-editor.org/rfc/rfc4737.txt", + key="RFC 4737", + abstract={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]}, + keywords="ippm", + doi="10.17487/RFC4737", + } + +@misc{rfc4738, + author="D. Ignjatic and L. Dondeti and F. Audet and P. Lin", + title="{MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)}", + howpublished="RFC 4738 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4738", + pages="1--19", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4738.txt", + key="RFC 4738", + abstract={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]}, + keywords="MIKEY, SRTP, key management, group key distribution, RSA-R", + doi="10.17487/RFC4738", + } + +@misc{rfc4739, + author="P. Eronen and J. Korhonen", + title="{Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol}", + howpublished="RFC 4739 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4739", + pages="1--11", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4739.txt", + key="RFC 4739", + abstract={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.}, + keywords="", + doi="10.17487/RFC4739", + } + +@misc{rfc4740, + author="M. {Garcia-Martin (Ed.)} and M. Belinchon and M. Pallares-Lopez and C. Canales-Valenzuela and K. Tammi", + title="{Diameter Session Initiation Protocol (SIP) Application}", + howpublished="RFC 4740 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4740", + pages="1--72", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4740.txt", + key="RFC 4740", + abstract={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]}, + keywords="authentication, authorization, diameter client", + doi="10.17487/RFC4740", + } + +@misc{rfc4741, + author="R. {Enns (Ed.)}", + title="{NETCONF Configuration Protocol}", + howpublished="RFC 4741 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4741", + pages="1--95", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6241", +url="https://www.rfc-editor.org/rfc/rfc4741.txt", + key="RFC 4741", + abstract={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]}, + keywords="network configuration protocol, network device, xml, extensible markup language, rpc, remote procedure call", + doi="10.17487/RFC4741", + } + +@misc{rfc4742, + author="M. Wasserman and T. Goddard", + title="{Using the NETCONF Configuration Protocol over Secure SHell (SSH)}", + howpublished="RFC 4742 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4742", + pages="1--10", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6242", +url="https://www.rfc-editor.org/rfc/rfc4742.txt", + key="RFC 4742", + abstract={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]}, + keywords="network configuration protocol", + doi="10.17487/RFC4742", + } + +@misc{rfc4743, + author="T. Goddard", + title="{Using NETCONF over the Simple Object Access Protocol (SOAP)}", + howpublished="RFC 4743 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4743", + pages="1--20", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4743.txt", + key="RFC 4743", + abstract={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]}, + keywords="NETCONF, XMLCONF, SOAP, device managment, XML, Extensible Markup Language", + doi="10.17487/RFC4743", + } + +@misc{rfc4744, + author="E. Lear and K. Crozier", + title="{Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)}", + howpublished="RFC 4744 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4744", + pages="1--10", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4744.txt", + key="RFC 4744", + abstract={This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]}, + keywords="XML, Configuration, Network Management, Extensible Markup Language", + doi="10.17487/RFC4744", + } + +@misc{rfc4745, + author="H. Schulzrinne and H. Tschofenig and J. Morris and J. Cuellar and J. Polk and J. Rosenberg", + title="{Common Policy: A Document Format for Expressing Privacy Preferences}", + howpublished="RFC 4745 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4745", + pages="1--32", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4745.txt", + key="RFC 4745", + abstract={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]}, + keywords="rules, conditions, permissions", + doi="10.17487/RFC4745", + } + +@misc{rfc4746, + author="T. Clancy and W. Arbaugh", + title="{Extensible Authentication Protocol (EAP) Password Authenticated Exchange}", + howpublished="RFC 4746 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4746", + pages="1--30", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4746.txt", + key="RFC 4746", + abstract={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.}, + keywords="EAP-PAX, password authenticated exchange, key exchange", + doi="10.17487/RFC4746", + } + +@misc{rfc4747, + author="S. Kipp and G. Ramkumar and K. McCloghrie", + title="{The Virtual Fabrics MIB}", + howpublished="RFC 4747 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4747", + pages="1--20", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4747.txt", + key="RFC 4747", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabrics function. [STANDARDS-TRACK]}, + keywords="management information base, T11-FC-VIRTUAL-FABRIC-MIB, fibre channel network, virtual fabric", + doi="10.17487/RFC4747", + } + +@misc{rfc4748, + author="S. {Bradner (Ed.)}", + title="{RFC 3978 Update to Recognize the IETF Trust}", + howpublished="RFC 4748 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4748", + pages="1--4", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5378", +url="https://www.rfc-editor.org/rfc/rfc4748.txt", + key="RFC 4748", + abstract={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. 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.}, + keywords="ipr, intellectual property rights, copyright", + doi="10.17487/RFC4748", + } + +@misc{rfc4749, + author="A. Sollaud", + title="{RTP Payload Format for the G.729.1 Audio Codec}", + howpublished="RFC 4749 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4749", + pages="1--14", + year=2006, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5459", +url="https://www.rfc-editor.org/rfc/rfc4749.txt", + key="RFC 4749", + abstract={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]}, + keywords="real-time transport protocol, itu-t, international telecommunication union", + doi="10.17487/RFC4749", + } + +@misc{rfc4750, + author="D. {Joyal (Ed.)} and P. {Galecki (Ed.)} and S. {Giacalone (Ed.)} and R. Coltun and F. Baker", + title="{OSPF Version 2 Management Information Base}", + howpublished="RFC 4750 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4750", + pages="1--121", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4750.txt", + key="RFC 4750", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing 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. 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]}, + keywords="OSPF-MIB, Open Shortest Path First, SPF, MIB, routing, network management mib, OSPF-MIB, OSPF-TRAP-MIB", + doi="10.17487/RFC4750", + } + +@misc{rfc4752, + author="A. {Melnikov (Ed.)}", + title="{The Kerberos V5 (``GSSAPI'') Simple Authentication and Security Layer (SASL) Mechanism}", + howpublished="RFC 4752 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4752", + pages="1--10", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4752.txt", + key="RFC 4752", + abstract={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. 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]}, + keywords="SASL, encryption, protocol, specific", + doi="10.17487/RFC4752", + } + +@misc{rfc4753, + author="D. Fu and J. Solinas", + title="{ECP Groups For IKE and IKEv2}", + howpublished="RFC 4753 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4753", + pages="1--16", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5903", +url="https://www.rfc-editor.org/rfc/rfc4753.txt", + key="RFC 4753", + abstract={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.}, + keywords="elliptic curve, Diffie-Hellman, suite b, nist curve", + doi="10.17487/RFC4753", + } + +@misc{rfc4754, + author="D. Fu and J. Solinas", + title="{IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)}", + howpublished="RFC 4754 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4754", + pages="1--15", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4754.txt", + key="RFC 4754", + abstract={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]}, + keywords="suite b", + doi="10.17487/RFC4754", + } + +@misc{rfc4755, + author="V. Kashyap", + title="{IP over InfiniBand: Connected Mode}", + howpublished="RFC 4755 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4755", + pages="1--13", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4755.txt", + key="RFC 4755", + abstract={This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4755", + } + +@misc{rfc4756, + author="A. Li", + title="{Forward Error Correction Grouping Semantics in Session Description Protocol}", + howpublished="RFC 4756 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4756", + pages="1--6", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5956", +url="https://www.rfc-editor.org/rfc/rfc4756.txt", + key="RFC 4756", + abstract={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]}, + keywords="fec, sdp, media lines", + doi="10.17487/RFC4756", + } + +@misc{rfc4757, + author="K. Jaganathan and L. Zhu and J. Brezak", + title="{The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows}", + howpublished="RFC 4757 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4757", + pages="1--18", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6649", +url="https://www.rfc-editor.org/rfc/rfc4757.txt", + key="RFC 4757", + abstract={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. 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.}, + keywords="md5 hmac", + doi="10.17487/RFC4757", + } + +@misc{rfc4758, + author="M. Nystroem", + title="{Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1}", + howpublished="RFC 4758 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4758", + pages="1--54", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4758.txt", + key="RFC 4758", + abstract={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. 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.}, + keywords="rsa laboratories, one-time password specifications, otps", + doi="10.17487/RFC4758", + } + +@misc{rfc4759, + author="R. Stastny and R. Shockey and L. Conroy", + title="{The ENUM Dip Indicator Parameter for the ``tel'' URI}", + howpublished="RFC 4759 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4759", + pages="1--8", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4759.txt", + key="RFC 4759", + abstract={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]}, + keywords="DNS, E.164, telephone number", + doi="10.17487/RFC4759", + } + +@misc{rfc4760, + author="T. Bates and R. Chandra and D. Katz and Y. Rekhter", + title="{Multiprotocol Extensions for BGP-4}", + howpublished="RFC 4760 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4760", + pages="1--12", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7606", +url="https://www.rfc-editor.org/rfc/rfc4760.txt", + key="RFC 4760", + abstract={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]}, + keywords="MEXT-BGP4, border gateway protocol, network layer protocols", + doi="10.17487/RFC4760", + } + +@misc{rfc4761, + author="K. {Kompella (Ed.)} and Y. {Rekhter (Ed.)}", + title="{Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling}", + howpublished="RFC 4761 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4761", + pages="1--28", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5462, 8395", +url="https://www.rfc-editor.org/rfc/rfc4761.txt", + key="RFC 4761", + abstract={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. 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]}, + keywords="border gateway protocol, transparent lan service, virtual private switched network, service provider", + doi="10.17487/RFC4761", + } + +@misc{rfc4762, + author="M. {Lasserre (Ed.)} and V. {Kompella (Ed.)}", + title="{Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling}", + howpublished="RFC 4762 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4762", + pages="1--31", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4762.txt", + key="RFC 4762", + abstract={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. 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]}, + keywords="land area network, transparent lan service", + doi="10.17487/RFC4762", + } + +@misc{rfc4763, + author="M. Vanderveen and H. Soliman", + title="{Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)}", + howpublished="RFC 4763 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4763", + pages="1--46", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4763.txt", + key="RFC 4763", + abstract={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.}, + keywords="IEEE 802.11i, user anonymity", + doi="10.17487/RFC4763", + } + +@misc{rfc4764, + author="F. Bersani and H. Tschofenig", + title="{The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method}", + howpublished="RFC 4764 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4764", + pages="1--64", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4764.txt", + key="RFC 4764", + abstract={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.}, + keywords="pre-shared key", + doi="10.17487/RFC4764", + } + +@misc{rfc4765, + author="H. Debar and D. Curry and B. Feinstein", + title="{The Intrusion Detection Message Exchange Format (IDMEF)}", + howpublished="RFC 4765 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4765", + pages="1--157", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4765.txt", + key="RFC 4765", + abstract={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. 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.}, + keywords="intrusion detection, security, secure, exchange, intrusion, IDS, XML", + doi="10.17487/RFC4765", + } + +@misc{rfc4766, + author="M. Wood and M. Erlinger", + title="{Intrusion Detection Message Exchange Requirements}", + howpublished="RFC 4766 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4766", + pages="1--25", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4766.txt", + key="RFC 4766", + abstract={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.}, + keywords="idmef, idwg, intrusion detection exchange format", + doi="10.17487/RFC4766", + } + +@misc{rfc4767, + author="B. Feinstein and G. Matthews", + title="{The Intrusion Detection Exchange Protocol (IDXP)}", + howpublished="RFC 4767 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4767", + pages="1--28", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4767.txt", + key="RFC 4767", + abstract={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.}, + keywords="intrusion, intrusion detection, beep, security, ids, security protocol, secure protocol, secure exchange, idmef", + doi="10.17487/RFC4767", + } + +@misc{rfc4768, + author="S. Hartman", + title="{Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming}", + howpublished="RFC 4768 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4768", + pages="1--12", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4768.txt", + key="RFC 4768", + abstract={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.}, + keywords="acl, access control list", + doi="10.17487/RFC4768", + } + +@misc{rfc4769, + author="J. Livingood and R. Shockey", + title="{IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information}", + howpublished="RFC 4769 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4769", + pages="1--13", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4769.txt", + key="RFC 4769", + abstract={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]}, + keywords="tel, uri, uri scheme, sip", + doi="10.17487/RFC4769", + } + +@misc{rfc4770, + author="C. Jennings and J. {Reschke (Ed.)}", + title="{vCard Extensions for Instant Messaging (IM)}", + howpublished="RFC 4770 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4770", + pages="1--7", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6350", +url="https://www.rfc-editor.org/rfc/rfc4770.txt", + key="RFC 4770", + abstract={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]}, + keywords="impp, instant messaging and presence protocol", + doi="10.17487/RFC4770", + } + +@misc{rfc4771, + author="V. Lehtovirta and M. Naslund and K. Norrman", + title="{Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)}", + howpublished="RFC 4771 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4771", + pages="1--12", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4771.txt", + key="RFC 4771", + abstract={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]}, + keywords="roc", + doi="10.17487/RFC4771", + } + +@misc{rfc4772, + author="S. Kelly", + title="{Security Implications of Using the Data Encryption Standard (DES)}", + howpublished="RFC 4772 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4772", + pages="1--28", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4772.txt", + key="RFC 4772", + abstract={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.}, + doi="10.17487/RFC4772", + } + +@misc{rfc4773, + author="G. Huston", + title="{Administration of the IANA Special Purpose IPv6 Address Block}", + howpublished="RFC 4773 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4773", + pages="1--5", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6890", +url="https://www.rfc-editor.org/rfc/rfc4773.txt", + key="RFC 4773", + abstract={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.}, + doi="10.17487/RFC4773", + } + +@misc{rfc4774, + author="S. Floyd", + title="{Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field}", + howpublished="RFC 4774 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4774", + pages="1--15", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6040", +url="https://www.rfc-editor.org/rfc/rfc4774.txt", + key="RFC 4774", + abstract={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.}, + keywords="", + doi="10.17487/RFC4774", + } + +@misc{rfc4775, + author="S. Bradner and B. {Carpenter (Ed.)} and T. Narten", + title="{Procedures for Protocol Extensions and Variations}", + howpublished="RFC 4775 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4775", + pages="1--14", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4775.txt", + key="RFC 4775", + abstract={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. 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.}, + keywords="sdo, standards development organization", + doi="10.17487/RFC4775", + } + +@misc{rfc4776, + author="H. Schulzrinne", + title="{Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information}", + howpublished="RFC 4776 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4776", + pages="1--19", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5774, 6848", +url="https://www.rfc-editor.org/rfc/rfc4776.txt", + key="RFC 4776", + abstract={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]}, + keywords="lci, local configuration information", + doi="10.17487/RFC4776", + } + +@misc{rfc4777, + author="T. {Murphy Jr.} and P. Rieth and J. Stevens", + title="{IBM's iSeries Telnet Enhancements}", + howpublished="RFC 4777 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4777", + pages="1--47", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4777.txt", + key="RFC 4777", + abstract={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. 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.}, + keywords="midrange business computer, telnet environment, client, server, printer", + doi="10.17487/RFC4777", + } + +@misc{rfc4778, + author="M. Kaeo", + title="{Operational Security Current Practices in Internet Service Provider Environments}", + howpublished="RFC 4778 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4778", + pages="1--37", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4778.txt", + key="RFC 4778", + abstract={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.}, + keywords="isp", + doi="10.17487/RFC4778", + } + +@misc{rfc4779, + author="S. Asadullah and A. Ahmed and C. Popoviciu and P. Savola and J. Palet", + title="{ISP IPv6 Deployment Scenarios in Broadband Access Networks}", + howpublished="RFC 4779 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4779", + pages="1--81", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4779.txt", + key="RFC 4779", + abstract={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.}, + keywords="v6ops, isp, ipv6, deployment, scenarios, broadband, networks", + doi="10.17487/RFC4779", + } + +@misc{rfc4780, + author="K. Lingle and J-F. Mule and J. Maeng and D. Walker", + title="{Management Information Base for the Session Initiation Protocol (SIP)}", + howpublished="RFC 4780 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4780", + pages="1--83", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4780.txt", + key="RFC 4780", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]}, + keywords="mib, registrar services, SIP-COMMON-MIB, SIP-TC-MIB, SIP-UA-MIB DEFINITIONS, SIP-SERVER-MIB", + doi="10.17487/RFC4780", + } + +@misc{rfc4781, + author="Y. Rekhter and R. Aggarwal", + title="{Graceful Restart Mechanism for BGP with MPLS}", + howpublished="RFC 4781 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4781", + pages="1--10", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4781.txt", + key="RFC 4781", + abstract={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. 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]}, + keywords="border gateway protocol, multiprotocol label switching, nlri, bgp network layer reachability information", + doi="10.17487/RFC4781", + } + +@misc{rfc4782, + author="S. Floyd and M. Allman and A. Jain and P. Sarolahti", + title="{Quick-Start for TCP and IP}", + howpublished="RFC 4782 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4782", + pages="1--82", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4782.txt", + key="RFC 4782", + abstract={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. 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.}, + keywords="", + doi="10.17487/RFC4782", + } + +@misc{rfc4783, + author="L. {Berger (Ed.)}", + title="{GMPLS - Communication of Alarm Information}", + howpublished="RFC 4783 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4783", + pages="1--19", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4783.txt", + key="RFC 4783", + abstract={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. 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]}, + keywords="generalized multiprotocol label switching, gmpls-rsvp", + doi="10.17487/RFC4783", + } + +@misc{rfc4784, + author="C. Carroll and F. Quick", + title="{Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks}", + howpublished="RFC 4784 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4784", + pages="1--45", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4784.txt", + key="RFC 4784", + abstract={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). cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.}, + keywords="mip, cryptographic keys, dmu", + doi="10.17487/RFC4784", + } + +@misc{rfc4785, + author="U. Blumenthal and P. Goel", + title="{Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)}", + howpublished="RFC 4785 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4785", + pages="1--5", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4785.txt", + key="RFC 4785", + abstract={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]}, + keywords="cipher suite", + doi="10.17487/RFC4785", + } + +@misc{rfc4786, + author="J. Abley and K. Lindqvist", + title="{Operation of Anycast Services}", + howpublished="RFC 4786 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4786", + pages="1--24", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4786.txt", + key="RFC 4786", + abstract={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. 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.}, + keywords="ROUTING, LOAD-BALANCING, LOAD-SHARING", + doi="10.17487/RFC4786", + } + +@misc{rfc4787, + author="F. {Audet (Ed.)} and C. Jennings", + title="{Network Address Translation (NAT) Behavioral Requirements for Unicast UDP}", + howpublished="RFC 4787 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4787", + pages="1--29", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6888, 7857", +url="https://www.rfc-editor.org/rfc/rfc4787.txt", + key="RFC 4787", + abstract={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.}, + keywords="nat, sip, udp", + doi="10.17487/RFC4787", + } + +@misc{rfc4788, + author="Q. Xie and R. Kapoor", + title="{Enhancements to RTP Payload Formats for EVRC Family Codecs}", + howpublished="RFC 4788 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4788", + pages="1--22", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5188", +url="https://www.rfc-editor.org/rfc/rfc4788.txt", + key="RFC 4788", + abstract={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]}, + keywords="enhanced variable rate codec, real time transmission protocol, evrc-b, dtx, discontinuous transmission", + doi="10.17487/RFC4788", + } + +@misc{rfc4789, + author="J. Schoenwaelder and T. Jeffree", + title="{Simple Network Management Protocol (SNMP) over IEEE 802 Networks}", + howpublished="RFC 4789 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4789", + pages="1--9", + year=2006, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4789.txt", + key="RFC 4789", + abstract={This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks. This document obsoletes RFC 1089. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC4789", + } + +@misc{rfc4790, + author="C. Newman and M. Duerst and A. Gulbrandsen", + title="{Internet Application Protocol Collation Registry}", + howpublished="RFC 4790 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4790", + pages="1--26", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4790.txt", + key="RFC 4790", + abstract={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]}, + keywords="collation, sorting", + doi="10.17487/RFC4790", + } + +@misc{rfc4791, + author="C. Daboo and B. Desruisseaux and L. Dusseault", + title="{Calendaring Extensions to WebDAV (CalDAV)}", + howpublished="RFC 4791 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4791", + pages="1--107", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5689, 6638, 6764, 7809, 7953", +url="https://www.rfc-editor.org/rfc/rfc4791.txt", + key="RFC 4791", + abstract={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]}, + keywords="calsched, calsch, calcav, calendar, calendaring, scheduling, webdav, ical, icalendar, itip, text/calendar, http", + doi="10.17487/RFC4791", + } + +@misc{rfc4792, + author="S. Legg", + title="{Encoding Instructions for the Generic String Encoding Rules (GSER)}", + howpublished="RFC 4792 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4792", + pages="1--9", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4792.txt", + key="RFC 4792", + abstract={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]}, + keywords="ASN.1", + doi="10.17487/RFC4792", + } + +@misc{rfc4793, + author="M. Nystroem", + title="{The EAP Protected One-Time Password Protocol (EAP-POTP)}", + howpublished="RFC 4793 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4793", + pages="1--82", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4793.txt", + key="RFC 4793", + abstract={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.}, + keywords="otp, extensible authentication protocol", + doi="10.17487/RFC4793", + } + +@misc{rfc4794, + author="B. Fenner", + title="{RFC 1264 Is Obsolete}", + howpublished="RFC 4794 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4794", + pages="1--4", + year=2006, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4794.txt", + key="RFC 4794", + abstract={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.}, + doi="10.17487/RFC4794", + } + +@misc{rfc4795, + author="B. Aboba and D. Thaler and L. Esibov", + title="{Link-local Multicast Name Resolution (LLMNR)}", + howpublished="RFC 4795 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4795", + pages="1--31", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4795.txt", + key="RFC 4795", + abstract={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.}, + doi="10.17487/RFC4795", + } + +@misc{rfc4796, + author="J. Hautakorpi and G. Camarillo", + title="{The Session Description Protocol (SDP) Content Attribute}", + howpublished="RFC 4796 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4796", + pages="1--11", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4796.txt", + key="RFC 4796", + abstract={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]}, + keywords="media attribute, content", + doi="10.17487/RFC4796", + } + +@misc{rfc4797, + author="Y. Rekhter and R. Bonica and E. Rosen", + title="{Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks}", + howpublished="RFC 4797 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4797", + pages="1--10", + year=2007, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4797.txt", + key="RFC 4797", + abstract={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). 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.}, + keywords="L3VPN GRE encapsulation", + doi="10.17487/RFC4797", + } + +@misc{rfc4798, + author="J. De Clercq and D. Ooms and S. Prevost and F. Le Faucheur", + title="{Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)}", + howpublished="RFC 4798 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4798", + pages="1--14", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4798.txt", + key="RFC 4798", + abstract={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]}, + keywords="mp-bgp", + doi="10.17487/RFC4798", + } + +@misc{rfc4801, + author="T. {Nadeau (Ed.)} and A. {Farrel (Ed.)}", + title="{Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management}", + howpublished="RFC 4801 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4801", + pages="1--9", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4801.txt", + key="RFC 4801", + abstract={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]}, + keywords="management information base, mib, GMPLS-TC-STD-MIB", + doi="10.17487/RFC4801", + } + +@misc{rfc4802, + author="T. {Nadeau (Ed.)} and A. Farrel and Ed.", + title="{Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base}", + howpublished="RFC 4802 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4802", + pages="1--60", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4802.txt", + key="RFC 4802", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. [STANDARDS-TRACK]}, + keywords="mib, GMPLS-TE-STD-MIB, IANA-GMPLS-TC-MIB", + doi="10.17487/RFC4802", + } + +@misc{rfc4803, + author="T. {Nadeau (Ed.)} and A. {Farrel (Ed.)}", + title="{Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base}", + howpublished="RFC 4803 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4803", + pages="1--42", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4803.txt", + key="RFC 4803", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). [STANDARDS-TRACK]}, + keywords="mib, GMPLS-LSR-STD-MIB, GMPLS-LABEL-STD-MIB", + doi="10.17487/RFC4803", + } + +@misc{rfc4804, + author="F. Le {Faucheur (Ed.)}", + title="{Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels}", + howpublished="RFC 4804 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4804", + pages="1--31", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4804.txt", + key="RFC 4804", + abstract={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]}, + keywords="multiprotocol label switching, traffic engineering, diffserv-aware mpls traffic engineering", + doi="10.17487/RFC4804", + } + +@misc{rfc4805, + author="O. {Nicklass (Ed.)}", + title="{Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types}", + howpublished="RFC 4805 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4805", + pages="1--94", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4805.txt", + key="RFC 4805", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, 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. This document obsoletes RFC 3895. [STANDARDS-TRACK]}, + keywords="mib, management information base, DS1-MIB", + doi="10.17487/RFC4805", + } + +@misc{rfc4806, + author="M. Myers and H. Tschofenig", + title="{Online Certificate Status Protocol (OCSP) Extensions to IKEv2}", + howpublished="RFC 4806 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4806", + pages="1--11", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4806.txt", + key="RFC 4806", + abstract={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. 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 peer s 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]}, + keywords="internet key exchange version 2", + doi="10.17487/RFC4806", + } + +@misc{rfc4807, + author="M. Baer and R. Charlet and W. Hardaker and R. Story and C. Wang", + title="{IPsec Security Policy Database Configuration MIB}", + howpublished="RFC 4807 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4807", + pages="1--71", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4807.txt", + key="RFC 4807", + abstract={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]}, + keywords="management information base, IPSEC-SPD-MIB", + doi="10.17487/RFC4807", + } + +@misc{rfc4808, + author="S. Bellovin", + title="{Key Change Strategies for TCP-MD5}", + howpublished="RFC 4808 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4808", + pages="1--8", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4808.txt", + key="RFC 4808", + abstract={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.}, + keywords="bgp, border gateway protocol", + doi="10.17487/RFC4808", + } + +@misc{rfc4809, + author="C. {Bonatti (Ed.)} and S. {Turner (Ed.)} and G. {Lebovitz (Ed.)}", + title="{Requirements for an IPsec Certificate Management Profile}", + howpublished="RFC 4809 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4809", + pages="1--45", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4809.txt", + key="RFC 4809", + abstract={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.}, + keywords="internet protocol security", + doi="10.17487/RFC4809", + } + +@misc{rfc4810, + author="C. Wallace and U. Pordesch and R. Brandner", + title="{Long-Term Archive Service Requirements}", + howpublished="RFC 4810 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4810", + pages="1--17", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4810.txt", + key="RFC 4810", + abstract={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.}, + keywords="data integrity, digital signatures", + doi="10.17487/RFC4810", + } + +@misc{rfc4811, + author="L. Nguyen and A. Roy and A. Zinin", + title="{OSPF Out-of-Band Link State Database (LSDB) Resynchronization}", + howpublished="RFC 4811 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4811", + pages="1--10", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4811.txt", + key="RFC 4811", + abstract={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. 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 thi s mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.}, + keywords="open shortest path first", + doi="10.17487/RFC4811", + } + +@misc{rfc4812, + author="L. Nguyen and A. Roy and A. Zinin", + title="{OSPF Restart Signaling}", + howpublished="RFC 4812 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4812", + pages="1--7", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4812.txt", + key="RFC 4812", + abstract={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. 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.}, + keywords="open shortest path first", + doi="10.17487/RFC4812", + } + +@misc{rfc4813, + author="B. Friedman and L. Nguyen and A. Roy and D. Yeung and A. Zinin", + title="{OSPF Link-Local Signaling}", + howpublished="RFC 4813 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4813", + pages="1--10", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5613", +url="https://www.rfc-editor.org/rfc/rfc4813.txt", + key="RFC 4813", + abstract={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.}, + keywords="open shortest path first", + doi="10.17487/RFC4813", + } + +@misc{rfc4814, + author="D. Newman and T. Player", + title="{Hash and Stuffing: Overlooked Factors in Network Device Benchmarking}", + howpublished="RFC 4814 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4814", + pages="1--26", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4814.txt", + key="RFC 4814", + abstract={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.}, + keywords="bmwg, benchmarking, testing, bit-stuffing, byte-stuffing", + doi="10.17487/RFC4814", + } + +@misc{rfc4815, + author="L-E. Jonsson and K. Sandlund and G. Pelletier and P. Kremer", + title="{RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095}", + howpublished="RFC 4815 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4815", + pages="1--33", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4815.txt", + key="RFC 4815", + abstract={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]}, + keywords="ip, udp, user datagram protocol, rtp, realtime transport protocol, esp, encapsulation security payload", + doi="10.17487/RFC4815", + } + +@misc{rfc4816, + author="A. Malis and L. Martini and J. Brayley and T. Walsh", + title="{Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service}", + howpublished="RFC 4816 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4816", + pages="1--5", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4816.txt", + key="RFC 4816", + abstract={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]}, + keywords="", + doi="10.17487/RFC4816", + } + +@misc{rfc4817, + author="M. Townsley and C. Pignataro and S. Wainner and T. Seely and J. Young", + title="{Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3}", + howpublished="RFC 4817 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4817", + pages="1--12", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4817.txt", + key="RFC 4817", + abstract={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]}, + keywords="l2tpv3, multiprotocol label switching label stack, label stack", + doi="10.17487/RFC4817", + } + +@misc{rfc4818, + author="J. Salowey and R. Droms", + title="{RADIUS Delegated-IPv6-Prefix Attribute}", + howpublished="RFC 4818 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4818", + pages="1--7", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4818.txt", + key="RFC 4818", + abstract={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]}, + keywords="remote authentication dial in user service, diameter", + doi="10.17487/RFC4818", + } + +@misc{rfc4819, + author="J. Galbraith and J. Van Dyke and J. Bright", + title="{Secure Shell Public Key Subsystem}", + howpublished="RFC 4819 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4819", + pages="1--17", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4819.txt", + key="RFC 4819", + abstract={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. 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. A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK]}, + keywords="ssh, ssh2", + doi="10.17487/RFC4819", + } + +@misc{rfc4820, + author="M. Tuexen and R. Stewart and P. Lei", + title="{Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)}", + howpublished="RFC 4820 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4820", + pages="1--6", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4820.txt", + key="RFC 4820", + abstract={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]}, + keywords="", + doi="10.17487/RFC4820", + } + +@misc{rfc4821, + author="M. Mathis and J. Heffner", + title="{Packetization Layer Path MTU Discovery}", + howpublished="RFC 4821 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4821", + pages="1--32", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4821.txt", + key="RFC 4821", + abstract={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]}, + keywords="maximum transmission unit, pmtud", + doi="10.17487/RFC4821", + } + +@misc{rfc4822, + author="R. Atkinson and M. Fanto", + title="{RIPv2 Cryptographic Authentication}", + howpublished="RFC 4822 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4822", + pages="1--22", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4822.txt", + key="RFC 4822", + abstract={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]}, + keywords="RIP2-MD5, Routing Information Protocol, Encryption", + doi="10.17487/RFC4822", + } + +@misc{rfc4823, + author="T. Harding and R. Scott", + title="{FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet}", + howpublished="RFC 4823 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4823", + pages="1--40", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4823.txt", + key="RFC 4823", + abstract={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.}, + keywords="applicability statement, as, business-to-business", + doi="10.17487/RFC4823", + } + +@misc{rfc4824, + author="J. {Hofmueller (Ed.)} and A. {Bachmann (Ed.)} and IO. {zmoelnig (Ed.)}", + title="{The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)}", + howpublished="RFC 4824 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4824", + pages="1--13", + year=2007, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4824.txt", + key="RFC 4824", + abstract={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.}, + keywords="internet protocol, april fools", + doi="10.17487/RFC4824", + } + +@misc{rfc4825, + author="J. Rosenberg", + title="{The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)}", + howpublished="RFC 4825 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4825", + pages="1--71", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4825.txt", + key="RFC 4825", + abstract={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]}, + keywords="sip, xml, http, rest, buddy list, simple, presence, data manipulation", + doi="10.17487/RFC4825", + } + +@misc{rfc4826, + author="J. Rosenberg", + title="{Extensible Markup Language (XML) Formats for Representing Resource Lists}", + howpublished="RFC 4826 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4826", + pages="1--31", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4826.txt", + key="RFC 4826", + abstract={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]}, + keywords="http, sip, xml, rest, buddy list, simple, presence, data manipulation", + doi="10.17487/RFC4826", + } + +@misc{rfc4827, + author="M. Isomaki and E. Leppanen", + title="{An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents}", + howpublished="RFC 4827 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4827", + pages="1--11", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4827.txt", + key="RFC 4827", + abstract={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]}, + keywords="PIDF, AUID, hard state, PUBLISH, SIP Presence, SIMPLE, pidf-manipulation, XCAP application usage", + doi="10.17487/RFC4827", + } + +@misc{rfc4828, + author="S. Floyd and E. Kohler", + title="{TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant}", + howpublished="RFC 4828 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4828", + pages="1--46", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4828.txt", + key="RFC 4828", + abstract={This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet. 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. 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.}, + keywords="transmission control protocol", + doi="10.17487/RFC4828", + } + +@misc{rfc4829, + author="J. de {Oliveira (Ed.)} and JP. {Vasseur (Ed.)} and L. Chen and C. Scoglio", + title="{Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering}", + howpublished="RFC 4829 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4829", + pages="1--19", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4829.txt", + key="RFC 4829", + abstract={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 com munity.}, + keywords="traffic engineering label switched path, te lsp, multiprotocol label switching protocol", + doi="10.17487/RFC4829", + } + +@misc{rfc4830, + author="J. {Kempf (Ed.)}", + title="{Problem Statement for Network-Based Localized Mobility Management (NETLMM)}", + howpublished="RFC 4830 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4830", + pages="1--13", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4830.txt", + key="RFC 4830", + abstract={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.}, + doi="10.17487/RFC4830", + } + +@misc{rfc4831, + author="J. {Kempf (Ed.)}", + title="{Goals for Network-Based Localized Mobility Management (NETLMM)}", + howpublished="RFC 4831 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4831", + pages="1--14", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4831.txt", + key="RFC 4831", + abstract={In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. This memo provides information for the Internet community.}, + doi="10.17487/RFC4831", + } + +@misc{rfc4832, + author="C. Vogt and J. Kempf", + title="{Security Threats to Network-Based Localized Mobility Management (NETLMM)}", + howpublished="RFC 4832 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4832", + pages="1--12", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4832.txt", + key="RFC 4832", + abstract={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.}, + keywords="localized mobility anchor, mobile access gateway, compromise, impersonation, man in the middle, denial of service, IP spoofing", + doi="10.17487/RFC4832", + } + +@misc{rfc4833, + author="E. Lear and P. Eggert", + title="{Timezone Options for DHCP}", + howpublished="RFC 4833 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4833", + pages="1--10", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4833.txt", + key="RFC 4833", + abstract={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]}, + keywords="time offset, posix, tz database, tz", + doi="10.17487/RFC4833", + } + +@misc{rfc4834, + author="T. {Morin (Ed.)}", + title="{Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)}", + howpublished="RFC 4834 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4834", + pages="1--37", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4834.txt", + key="RFC 4834", + abstract={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.}, + keywords="vpn, virtual private networks, l3", + doi="10.17487/RFC4834", + } + +@misc{rfc4835, + author="V. Manral", + title="{Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)}", + howpublished="RFC 4835 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4835", + pages="1--10", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7321", +url="https://www.rfc-editor.org/rfc/rfc4835.txt", + key="RFC 4835", + abstract={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]}, + keywords="ESP, ipsec, authentication, mechanism, header, security, architecture, payload, internet, protocol, encapsulating, ipv4, ipv6", + doi="10.17487/RFC4835", + } + +@misc{rfc4836, + author="E. Beili", + title="{Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)}", + howpublished="RFC 4836 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4836", + pages="1--67", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4836.txt", + key="RFC 4836", + abstract={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]}, + keywords="MAU-MIB, IANA-MAU-MIB, management information base,", + doi="10.17487/RFC4836", + } + +@misc{rfc4837, + author="L. Khermosh", + title="{Managed Objects of Ethernet Passive Optical Networks (EPON)}", + howpublished="RFC 4837 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4837", + pages="1--91", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4837.txt", + key="RFC 4837", + abstract={This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing 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]}, + keywords="Ethernet Passive Optical Networks, pon, epon, IEEE802.3ah, 802.3ah, p2mp, mpcp, llid, onu, olt, optical access", + doi="10.17487/RFC4837", + } + +@misc{rfc4838, + author="V. Cerf and S. Burleigh and A. Hooke and L. Torgerson and R. Durst and K. Scott and K. Fall and H. Weiss", + title="{Delay-Tolerant Networking Architecture}", + howpublished="RFC 4838 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4838", + pages="1--35", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4838.txt", + key="RFC 4838", + abstract={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.}, + keywords="disruption tolerant, irtf, interplanetary internet", + doi="10.17487/RFC4838", + } + +@misc{rfc4839, + author="G. Conboy and J. Rivlin and J. Ferraiolo", + title="{Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF)}", + howpublished="RFC 4839 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4839", + pages="1--5", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4839.txt", + key="RFC 4839", + abstract={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.}, + doi="10.17487/RFC4839", + } + +@misc{rfc4840, + author="B. {Aboba (Ed.)} and E. Davies and D. Thaler", + title="{Multiple Encapsulation Methods Considered Harmful}", + howpublished="RFC 4840 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4840", + pages="1--27", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4840.txt", + key="RFC 4840", + abstract={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.}, + keywords="iab, link-layer protocol, ip encapsulation, internet protocol encapsulation", + doi="10.17487/RFC4840", + } + +@misc{rfc4841, + author="C. {Heard (Ed.)}", + title="{RFC 4181 Update to Recognize the IETF Trust}", + howpublished="RFC 4841 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4841", + pages="1--3", + year=2007, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4841.txt", + key="RFC 4841", + abstract={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.}, + keywords="management information base, standards-track specifications, mib review", + doi="10.17487/RFC4841", + } + +@misc{rfc4842, + author="A. Malis and P. Pate and R. {Cohen (Ed.)} and D. Zelig", + title="{Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)}", + howpublished="RFC 4842 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4842", + pages="1--43", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4842.txt", + key="RFC 4842", + abstract={This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]}, + keywords="multiprotocol label switching", + doi="10.17487/RFC4842", + } + +@misc{rfc4843, + author="P. Nikander and J. Laganier and F. Dupont", + title="{An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)}", + howpublished="RFC 4843 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4843", + pages="1--14", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7343", +url="https://www.rfc-editor.org/rfc/rfc4843.txt", + key="RFC 4843", + abstract={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. 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 r eturned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.}, + keywords="", + doi="10.17487/RFC4843", + } + +@misc{rfc4844, + author="L. {Daigle (Ed.)} and Internet Architecture Board", + title="{The RFC Series and RFC Editor}", + howpublished="RFC 4844 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4844", + pages="1--20", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5741", +url="https://www.rfc-editor.org/rfc/rfc4844.txt", + key="RFC 4844", + abstract={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.}, + keywords="technical publisher", + doi="10.17487/RFC4844", + } + +@misc{rfc4845, + author="L. {Daigle (Ed.)} and Internet Architecture Board", + title="{Process for Publication of IAB RFCs}", + howpublished="RFC 4845 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4845", + pages="1--5", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4845.txt", + key="RFC 4845", + abstract={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.}, + doi="10.17487/RFC4845", + } + +@misc{rfc4846, + author="J. {Klensin (Ed.)} and D. {Thaler (Ed.)}", + title="{Independent Submissions to the RFC Editor}", + howpublished="RFC 4846 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4846", + pages="1--16", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5744", +url="https://www.rfc-editor.org/rfc/rfc4846.txt", + key="RFC 4846", + abstract={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.}, + doi="10.17487/RFC4846", + } + +@misc{rfc4847, + author="T. {Takeda (Ed.)}", + title="{Framework and Requirements for Layer 1 Virtual Private Networks}", + howpublished="RFC 4847 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4847", + pages="1--38", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4847.txt", + key="RFC 4847", + abstract={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. 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.}, + keywords="L1VPN", + doi="10.17487/RFC4847", + } + +@misc{rfc4848, + author="L. Daigle", + title="{Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)}", + howpublished="RFC 4848 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4848", + pages="1--10", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4848.txt", + key="RFC 4848", + abstract={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]}, + keywords="service-parms, service parameters", + doi="10.17487/RFC4848", + } + +@misc{rfc4849, + author="P. Congdon and M. Sanchez and B. Aboba", + title="{RADIUS Filter Rule Attribute}", + howpublished="RFC 4849 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4849", + pages="1--9", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4849.txt", + key="RFC 4849", + abstract={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]}, + keywords="remote authentication dial in user service, nas-filter-rule", + doi="10.17487/RFC4849", + } + +@misc{rfc4850, + author="D. Wysochanski", + title="{Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture}", + howpublished="RFC 4850 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4850", + pages="1--9", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7143", +url="https://www.rfc-editor.org/rfc/rfc4850.txt", + key="RFC 4850", + abstract={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]}, + keywords="transport protocol, tcp, transmission control protocol", + doi="10.17487/RFC4850", + } + +@misc{rfc4851, + author="N. Cam-Winget and D. McGrew and J. Salowey and H. Zhou", + title="{The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)}", + howpublished="RFC 4851 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4851", + pages="1--64", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4851.txt", + key="RFC 4851", + abstract={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.}, + keywords="eap", + doi="10.17487/RFC4851", + } + +@misc{rfc4852, + author="J. Bound and Y. Pouffary and S. Klynsma and T. Chown and D. Green", + title="{IPv6 Enterprise Network Analysis - IP Layer 3 Focus}", + howpublished="RFC 4852 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4852", + pages="1--32", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4852.txt", + key="RFC 4852", + abstract={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.}, + keywords="internet protocol version 6, notational network", + doi="10.17487/RFC4852", + } + +@misc{rfc4853, + author="R. Housley", + title="{Cryptographic Message Syntax (CMS) Multiple Signer Clarification}", + howpublished="RFC 4853 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4853", + pages="1--5", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4853.txt", + key="RFC 4853", + abstract={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]}, + keywords="signeddata, digitally sign, authenticate, encrypt, arbitrary message content", + doi="10.17487/RFC4853", + } + +@misc{rfc4854, + author="P. Saint-Andre", + title="{A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 4854 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4854", + pages="1--9", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4854.txt", + key="RFC 4854", + abstract={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.}, + keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Instant Messaging, Presence, Uniform Resource Name, URN", + doi="10.17487/RFC4854", + } + +@misc{rfc4855, + author="S. Casner", + title="{Media Type Registration of RTP Payload Formats}", + howpublished="RFC 4855 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4855", + pages="1--11", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4855.txt", + key="RFC 4855", + abstract={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]}, + keywords="realtime transport protocol, multipurpose internet mail extensions", + doi="10.17487/RFC4855", + } + +@misc{rfc4856, + author="S. Casner", + title="{Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences}", + howpublished="RFC 4856 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4856", + pages="1--29", + year=2007, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4856.txt", + key="RFC 4856", + abstract={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]}, + keywords="realtime transport protocol, multipurpose internet mail extensions", + doi="10.17487/RFC4856", + } + +@misc{rfc4857, + author="E. Fogelstroem and A. Jonsson and C. Perkins", + title="{Mobile IPv4 Regional Registration}", + howpublished="RFC 4857 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4857", + pages="1--35", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4857.txt", + key="RFC 4857", + abstract={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.}, + keywords="GFA, gateway foreign agent", + doi="10.17487/RFC4857", + } + +@misc{rfc4858, + author="H. Levkowetz and D. Meyer and L. Eggert and A. Mankin", + title="{Document Shepherding from Working Group Last Call to Publication}", + howpublished="RFC 4858 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4858", + pages="1--21", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4858.txt", + key="RFC 4858", + abstract={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.}, + keywords="document shepherding, ietf documents", + doi="10.17487/RFC4858", + } + +@misc{rfc4859, + author="A. Farrel", + title="{Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object}", + howpublished="RFC 4859 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4859", + pages="1--5", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4859.txt", + key="RFC 4859", + abstract={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.}, + doi="10.17487/RFC4859", + } + +@misc{rfc4860, + author="F. Le Faucheur and B. Davie and P. Bose and C. Christou and M. Davenport", + title="{Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations}", + howpublished="RFC 4860 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4860", + pages="1--32", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4860.txt", + key="RFC 4860", + abstract={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 b e 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]}, + keywords="session object, session of interest, phb, per hop behavior", + doi="10.17487/RFC4860", + } + +@misc{rfc4861, + author="T. Narten and E. Nordmark and W. Simpson and H. Soliman", + title="{Neighbor Discovery for IP version 6 (IPv6)}", + howpublished="RFC 4861 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4861", + pages="1--97", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425", +url="https://www.rfc-editor.org/rfc/rfc4861.txt", + key="RFC 4861", + abstract={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]}, + keywords="IPV6-ND, internet protocol, link-layer, link-layer address", + doi="10.17487/RFC4861", + } + +@misc{rfc4862, + author="S. Thomson and T. Narten and T. Jinmei", + title="{IPv6 Stateless Address Autoconfiguration}", + howpublished="RFC 4862 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4862", + pages="1--30", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7527", +url="https://www.rfc-editor.org/rfc/rfc4862.txt", + key="RFC 4862", + abstract={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]}, + keywords="IPV6-AUTO, host, link-local, internet protocol version 6, link-local address, duplicate address detection", + doi="10.17487/RFC4862", + } + +@misc{rfc4863, + author="L. Martini and G. Swallow", + title="{Wildcard Pseudowire Type}", + howpublished="RFC 4863 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4863", + pages="1--6", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4863.txt", + key="RFC 4863", + abstract={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]}, + keywords="pw type, pw", + doi="10.17487/RFC4863", + } + +@misc{rfc4864, + author="G. Van de Velde and T. Hain and R. Droms and B. Carpenter and E. Klein", + title="{Local Network Protection for IPv6}", + howpublished="RFC 4864 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4864", + pages="1--36", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4864.txt", + key="RFC 4864", + abstract={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.}, + keywords="ipv6, address, protection, nat", + doi="10.17487/RFC4864", + } + +@misc{rfc4865, + author="G. White and G. Vaudreuil", + title="{SMTP Submission Service Extension for Future Message Release}", + howpublished="RFC 4865 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4865", + pages="1--11", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4865.txt", + key="RFC 4865", + abstract={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]}, + keywords="simple mail transfer protocol, future-release-integer", + doi="10.17487/RFC4865", + } + +@misc{rfc4866, + author="J. Arkko and C. Vogt and W. Haddad", + title="{Enhanced Route Optimization for Mobile IPv6}", + howpublished="RFC 4866 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4866", + pages="1--54", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4866.txt", + key="RFC 4866", + abstract={This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS-TRACK]}, + keywords="mobility, cryptographically generated addresses, cga, credit-based authorization, cba", + doi="10.17487/RFC4866", + } + +@misc{rfc4867, + author="J. Sjoberg and M. Westerlund and A. Lakaniemi and Q. Xie", + title="{RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs}", + howpublished="RFC 4867 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4867", + pages="1--59", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4867.txt", + key="RFC 4867", + abstract={This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate 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]}, + keywords="interoperate, applications", + doi="10.17487/RFC4867", + } + +@misc{rfc4868, + author="S. Kelly and S. Frankel", + title="{Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec}", + howpublished="RFC 4868 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4868", + pages="1--21", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4868.txt", + key="RFC 4868", + abstract={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]}, + keywords="hashed authentication mode, data authentication, integrity verification", + doi="10.17487/RFC4868", + } + +@misc{rfc4869, + author="L. Law and J. Solinas", + title="{Suite B Cryptographic Suites for IPsec}", + howpublished="RFC 4869 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4869", + pages="1--9", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6379", +url="https://www.rfc-editor.org/rfc/rfc4869.txt", + key="RFC 4869", + abstract={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.}, + keywords="ui suites, user interface suites, elliptic curve, ike", + doi="10.17487/RFC4869", + } + +@misc{rfc4870, + author="M. Delany", + title="{Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)}", + howpublished="RFC 4870 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4870", + pages="1--41", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4871", +url="https://www.rfc-editor.org/rfc/rfc4870.txt", + key="RFC 4870", + abstract={``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. 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. 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.}, + doi="10.17487/RFC4870", + } + +@misc{rfc4871, + author="E. Allman and J. Callas and M. Delany and M. Libbey and J. Fenton and M. Thomas", + title="{DomainKeys Identified Mail (DKIM) Signatures}", + howpublished="RFC 4871 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4871", + pages="1--71", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6376, updated by RFC 5672", +url="https://www.rfc-editor.org/rfc/rfc4871.txt", + key="RFC 4871", + abstract={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]}, + keywords="internet mail, authentication, spam, phishing, spoofing, digital signature", + doi="10.17487/RFC4871", + } + +@misc{rfc4872, + author="J.P. {Lang (Ed.)} and Y. {Rekhter (Ed.)} and D. {Papadimitriou (Ed.)}", + title="{RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery}", + howpublished="RFC 4872 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4872", + pages="1--47", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 4873, 6780", +url="https://www.rfc-editor.org/rfc/rfc4872.txt", + key="RFC 4872", + abstract={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]}, + keywords="resource reservation protocol, traffic engineering", + doi="10.17487/RFC4872", + } + +@misc{rfc4873, + author="L. Berger and I. Bryskin and D. Papadimitriou and A. Farrel", + title="{GMPLS Segment Recovery}", + howpublished="RFC 4873 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4873", + pages="1--25", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4873.txt", + key="RFC 4873", + abstract={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]}, + keywords="generalized multipoint label switching, rsvp-te, resource reservation protocol, traffic engineering, NOTIFY\_REQUEST", + doi="10.17487/RFC4873", + } + +@misc{rfc4874, + author="CY. Lee and A. Farrel and S. De Cnodder", + title="{Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)}", + howpublished="RFC 4874 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4874", + pages="1--27", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6001, 8390", +url="https://www.rfc-editor.org/rfc/rfc4874.txt", + key="RFC 4874", + abstract={This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). 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. 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]}, + keywords="srlg, shared risk link groups", + doi="10.17487/RFC4874", + } + +@misc{rfc4875, + author="R. {Aggarwal (Ed.)} and D. {Papadimitriou (Ed.)} and S. {Yasukawa (Ed.)}", + title="{Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)}", + howpublished="RFC 4875 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4875", + pages="1--53", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6510", +url="https://www.rfc-editor.org/rfc/rfc4875.txt", + key="RFC 4875", + abstract={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. 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]}, + keywords="p2mp, point-to-multipoint, traffic engineering", + doi="10.17487/RFC4875", + } + +@misc{rfc4876, + author="B. {Neal-Joslin (Ed.)} and L. Howard and M. Ansari", + title="{A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents}", + howpublished="RFC 4876 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4876", + pages="1--39", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4876.txt", + key="RFC 4876", + abstract={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.}, + keywords="ldap, schema, profile, configuration, nameservice, nss, pam\_ldap, nss\_ldap, rfc2307, rfc 2307", + doi="10.17487/RFC4876", + } + +@misc{rfc4877, + author="V. Devarapalli and F. Dupont", + title="{Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture}", + howpublished="RFC 4877 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4877", + pages="1--26", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4877.txt", + key="RFC 4877", + abstract={This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS-TRACK]}, + keywords="Bootstrapping, MIP6, Selector Granularity, Mobility Header, EAP Authentication", + doi="10.17487/RFC4877", + } + +@misc{rfc4878, + author="M. Squire", + title="{Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces}", + howpublished="RFC 4878 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4878", + pages="1--58", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4878.txt", + key="RFC 4878", + abstract={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]}, + keywords="efm, ethernet in the first mile, snmp, DOT3-OAM-MIB", + doi="10.17487/RFC4878", + } + +@misc{rfc4879, + author="T. Narten", + title="{Clarification of the Third Party Disclosure Procedure in RFC 3979}", + howpublished="RFC 4879 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4879", + pages="1--4", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8179", +url="https://www.rfc-editor.org/rfc/rfc4879.txt", + key="RFC 4879", + abstract={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.}, + keywords="ipr, copyright", + doi="10.17487/RFC4879", + } + +@misc{rfc4880, + author="J. Callas and L. Donnerhacke and H. Finney and D. Shaw and R. Thayer", + title="{OpenPGP Message Format}", + howpublished="RFC 4880 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4880", + pages="1--90", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5581", +url="https://www.rfc-editor.org/rfc/rfc4880.txt", + key="RFC 4880", + abstract={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. 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]}, + keywords="public-key cryptography, symmetric cryptography", + doi="10.17487/RFC4880", + } + +@misc{rfc4881, + author="K. El {Malki (Ed.)}", + title="{Low-Latency Handoffs in Mobile IPv4}", + howpublished="RFC 4881 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4881", + pages="1--64", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4881.txt", + key="RFC 4881", + abstract={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.}, + keywords="mip4", + doi="10.17487/RFC4881", + } + +@misc{rfc4882, + author="R. Koodli", + title="{IP Address Location Privacy and Mobile IPv6: Problem Statement}", + howpublished="RFC 4882 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4882", + pages="1--11", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4882.txt", + key="RFC 4882", + abstract={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.}, + keywords="internet protocol, home address, care-of address", + doi="10.17487/RFC4882", + } + +@misc{rfc4883, + author="G. Feher and K. Nemeth and A. Korn and I. Cselenyi", + title="{Benchmarking Terminology for Resource Reservation Capable Routers}", + howpublished="RFC 4883 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4883", + pages="1--24", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4883.txt", + key="RFC 4883", + abstract={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.}, + keywords="intserv, integrated services, benchmarking methodologies", + doi="10.17487/RFC4883", + } + +@misc{rfc4884, + author="R. Bonica and D. Gan and D. Tappan and C. Pignataro", + title="{Extended ICMP to Support Multi-Part Messages}", + howpublished="RFC 4884 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4884", + pages="1--19", + year=2007, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8335", +url="https://www.rfc-editor.org/rfc/rfc4884.txt", + key="RFC 4884", + abstract={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. 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. 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 doe s 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. 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. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]}, + keywords="internet control message protocol, length attribute", + doi="10.17487/RFC4884", + } + +@misc{rfc4885, + author="T. Ernst and H-Y. Lach", + title="{Network Mobility Support Terminology}", + howpublished="RFC 4885 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4885", + pages="1--19", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4885.txt", + key="RFC 4885", + abstract={This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements. This memo provides information for the Internet community.}, + keywords="nemo", + doi="10.17487/RFC4885", + } + +@misc{rfc4886, + author="T. Ernst", + title="{Network Mobility Support Goals and Requirements}", + howpublished="RFC 4886 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4886", + pages="1--13", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4886.txt", + key="RFC 4886", + abstract={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.}, + keywords="nemo", + doi="10.17487/RFC4886", + } + +@misc{rfc4887, + author="P. Thubert and R. Wakikawa and V. Devarapalli", + title="{Network Mobility Home Network Models}", + howpublished="RFC 4887 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4887", + pages="1--19", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4887.txt", + key="RFC 4887", + abstract={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.}, + keywords="nemo, mobile routers", + doi="10.17487/RFC4887", + } + +@misc{rfc4888, + author="C. Ng and P. Thubert and M. Watari and F. Zhao", + title="{Network Mobility Route Optimization Problem Statement}", + howpublished="RFC 4888 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4888", + pages="1--26", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4888.txt", + key="RFC 4888", + abstract={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.}, + keywords="nemo", + doi="10.17487/RFC4888", + } + +@misc{rfc4889, + author="C. Ng and F. Zhao and M. Watari and P. Thubert", + title="{Network Mobility Route Optimization Solution Space Analysis}", + howpublished="RFC 4889 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4889", + pages="1--38", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4889.txt", + key="RFC 4889", + abstract={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.}, + keywords="nemo, mrha, mobile router and home agent, ro", + doi="10.17487/RFC4889", + } + +@misc{rfc4890, + author="E. Davies and J. Mohacsi", + title="{Recommendations for Filtering ICMPv6 Messages in Firewalls}", + howpublished="RFC 4890 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4890", + pages="1--38", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4890.txt", + key="RFC 4890", + abstract={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. 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.}, + keywords="Internet Control Message Protocol version 6, ipv6, security, filter, firewall, icmpv6", + doi="10.17487/RFC4890", + } + +@misc{rfc4891, + author="R. Graveman and M. Parthasarathy and P. Savola and H. Tschofenig", + title="{Using IPsec to Secure IPv6-in-IPv4 Tunnels}", + howpublished="RFC 4891 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4891", + pages="1--23", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4891.txt", + key="RFC 4891", + abstract={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.}, + keywords="internet protocol, internet protocol security, ip security", + doi="10.17487/RFC4891", + } + +@misc{rfc4892, + author="S. Woolf and D. Conrad", + title="{Requirements for a Mechanism Identifying a Name Server Instance}", + howpublished="RFC 4892 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4892", + pages="1--8", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4892.txt", + key="RFC 4892", + abstract={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.}, + keywords="domain name service, dns name server", + doi="10.17487/RFC4892", + } + +@misc{rfc4893, + author="Q. Vohra and E. Chen", + title="{BGP Support for Four-octet AS Number Space}", + howpublished="RFC 4893 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4893", + pages="1--10", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6793", +url="https://www.rfc-editor.org/rfc/rfc4893.txt", + key="RFC 4893", + abstract={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]}, + keywords="autonomous system, border gateway protocol", + doi="10.17487/RFC4893", + } + +@misc{rfc4894, + author="P. Hoffman", + title="{Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec}", + howpublished="RFC 4894 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4894", + pages="1--11", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4894.txt", + key="RFC 4894", + abstract={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.}, + keywords="md5, pkix, certificates", + doi="10.17487/RFC4894", + } + +@misc{rfc4895, + author="M. Tuexen and R. Stewart and P. Lei and E. Rescorla", + title="{Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)}", + howpublished="RFC 4895 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4895", + pages="1--19", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4895.txt", + key="RFC 4895", + abstract={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]}, + keywords="chunk type, shared keys, RANDOM, CHUNKS, HMAC-ALGO", + doi="10.17487/RFC4895", + } + +@misc{rfc4896, + author="A. Surtees and M. West and A.B. Roach", + title="{Signaling Compression (SigComp) Corrections and Clarifications}", + howpublished="RFC 4896 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4896", + pages="1--28", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4896.txt", + key="RFC 4896", + abstract={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]}, + keywords="sip, session initiation protocol, udvm, universal decompressor virtual machine, algorithm", + doi="10.17487/RFC4896", + } + +@misc{rfc4897, + author="J. Klensin and S. Hartman", + title="{Handling Normative References to Standards-Track Documents}", + howpublished="RFC 4897 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4897", + pages="1--6", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4897.txt", + key="RFC 4897", + abstract={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.}, + keywords="", + doi="10.17487/RFC4897", + } + +@misc{rfc4898, + author="M. Mathis and J. Heffner and R. Raghunarayan", + title="{TCP Extended Statistics MIB}", + howpublished="RFC 4898 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4898", + pages="1--75", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4898.txt", + key="RFC 4898", + abstract={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]}, + keywords="transmission control protocol, management information base, TCP-ESTATS-MIB", + doi="10.17487/RFC4898", + } + +@misc{rfc4901, + author="J. {Ash (Ed.)} and J. {Hand (Ed.)} and A. {Malis (Ed.)}", + title="{Protocol Extensions for Header Compression over MPLS}", + howpublished="RFC 4901 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4901", + pages="1--34", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4901.txt", + key="RFC 4901", + abstract={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]}, + keywords="multiprotocol label switching, hc", + doi="10.17487/RFC4901", + } + +@misc{rfc4902, + author="M. Stecher", + title="{Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP}", + howpublished="RFC 4902 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4902", + pages="1--14", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4902.txt", + key="RFC 4902", + abstract={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. 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 f or the Internet community.}, + doi="10.17487/RFC4902", + } + +@misc{rfc4903, + author="D. Thaler", + title="{Multi-Link Subnet Issues}", + howpublished="RFC 4903 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4903", + pages="1--17", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4903.txt", + key="RFC 4903", + abstract={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.}, + doi="10.17487/RFC4903", + } + +@misc{rfc4904, + author="V. Gurbani and C. Jennings", + title="{Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)}", + howpublished="RFC 4904 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4904", + pages="1--19", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4904.txt", + key="RFC 4904", + abstract={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]}, + keywords="SIP TEL, Trunk group, trunkgroup, PSTN", + doi="10.17487/RFC4904", + } + +@misc{rfc4905, + author="L. {Martini (Ed.)} and E. {Rosen (Ed.)} and N. {El-Aawar (Ed.)}", + title="{Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks}", + howpublished="RFC 4905 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4905", + pages="1--20", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4905.txt", + key="RFC 4905", + abstract={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.}, + keywords="multiprotocol label switching, pdu, protocol data unit, draft-martini", + doi="10.17487/RFC4905", + } + +@misc{rfc4906, + author="L. {Martini (Ed.)} and E. {Rosen (Ed.)} and N. {El-Aawar (Ed.)}", + title="{Transport of Layer 2 Frames Over MPLS}", + howpublished="RFC 4906 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="4906", + pages="1--22", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4906.txt", + key="RFC 4906", + abstract={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.}, + keywords="multiprotocol label switching, pdu, protocol data unit, sonet, synchronized optical network", + doi="10.17487/RFC4906", + } + +@misc{rfc4907, + author="B. {Aboba (Ed.)}", + title="{Architectural Implications of Link Indications}", + howpublished="RFC 4907 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4907", + pages="1--62", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4907.txt", + key="RFC 4907", + abstract={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.}, + doi="10.17487/RFC4907", + } + +@misc{rfc4908, + author="K. Nagami and S. Uda and N. Ogashiwa and H. Esaki and R. Wakikawa and H. Ohnishi", + title="{Multi-homing for small scale fixed network Using Mobile IP and NEMO}", + howpublished="RFC 4908 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4908", + pages="1--10", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4908.txt", + key="RFC 4908", + abstract={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.}, + keywords="care-of addresses", + doi="10.17487/RFC4908", + } + +@misc{rfc4909, + author="L. {Dondeti (Ed.)} and D. Castleford and F. Hartung", + title="{Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport}", + howpublished="RFC 4909 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4909", + pages="1--7", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 5410, 6309", +url="https://www.rfc-editor.org/rfc/rfc4909.txt", + key="RFC 4909", + abstract={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.}, + keywords="short-term key message, long-term key message, oma, bac, browser and content, broadcast", + doi="10.17487/RFC4909", + } + +@misc{rfc4910, + author="S. Legg and D. Prager", + title="{Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)}", + howpublished="RFC 4910 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4910", + pages="1--80", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4910.txt", + key="RFC 4910", + abstract={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.}, + keywords="extensible markup language, canonical rxer, crxer", + doi="10.17487/RFC4910", + } + +@misc{rfc4911, + author="S. Legg", + title="{Encoding Instructions for the Robust XML Encoding Rules (RXER)}", + howpublished="RFC 4911 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4911", + pages="1--91", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4911.txt", + key="RFC 4911", + abstract={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.}, + keywords="extensible markup language, asn.1, abstract syntax notation one, robust xml encoding rules, rxer, canonical robust xml encoding rules, crxer, asn.x", + doi="10.17487/RFC4911", + } + +@misc{rfc4912, + author="S. Legg", + title="{Abstract Syntax Notation X (ASN.X)}", + howpublished="RFC 4912 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4912", + pages="1--165", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4912.txt", + key="RFC 4912", + abstract={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.}, + keywords="extensible markup language, asn.1, abstract syntax notation one, robust xml encoding rules, rxer", + doi="10.17487/RFC4912", + } + +@misc{rfc4913, + author="S. Legg", + title="{Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)}", + howpublished="RFC 4913 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4913", + pages="1--9", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4913.txt", + key="RFC 4913", + abstract={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.}, + keywords="extensible markup language", + doi="10.17487/RFC4913", + } + +@misc{rfc4914, + author="S. Legg", + title="{Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)}", + howpublished="RFC 4914 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4914", + pages="1--38", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4914.txt", + key="RFC 4914", + abstract={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.}, + keywords="extensible markup language", + doi="10.17487/RFC4914", + } + +@misc{rfc4915, + author="P. Psenak and S. Mirtorabi and A. Roy and L. Nguyen and P. Pillay-Esnault", + title="{Multi-Topology (MT) Routing in OSPF}", + howpublished="RFC 4915 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4915", + pages="1--20", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4915.txt", + key="RFC 4915", + abstract={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. An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]}, + keywords="open shortest path first", + doi="10.17487/RFC4915", + } + +@misc{rfc4916, + author="J. Elwell", + title="{Connected Identity in the Session Initiation Protocol (SIP)}", + howpublished="RFC 4916 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4916", + pages="1--24", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4916.txt", + key="RFC 4916", + abstract={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]}, + keywords="user agent, ua, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC4916", + } + +@misc{rfc4917, + author="V. Sastry and K. Leung and A. Patel", + title="{Mobile IPv4 Message String Extension}", + howpublished="RFC 4917 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4917", + pages="1--7", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4917.txt", + key="RFC 4917", + abstract={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]}, + keywords="home agent, foreign agent, registration reply", + doi="10.17487/RFC4917", + } + +@misc{rfc4918, + author="L. {Dusseault (Ed.)}", + title="{HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)}", + howpublished="RFC 4918 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4918", + pages="1--127", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5689", +url="https://www.rfc-editor.org/rfc/rfc4918.txt", + key="RFC 4918", + abstract={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). RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]}, + keywords="WEBDAV, hypertext, transfer, protocol, web, content", + doi="10.17487/RFC4918", + } + +@misc{rfc4919, + author="N. Kushalnagar and G. Montenegro and C. Schumacher", + title="{IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals}", + howpublished="RFC 4919 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4919", + pages="1--12", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4919.txt", + key="RFC 4919", + abstract={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.}, + keywords="ieee 802.15.4", + doi="10.17487/RFC4919", + } + +@misc{rfc4920, + author="A. {Farrel (Ed.)} and A. Satyanarayana and A. Iwata and N. Fujita and G. Ash", + title="{Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE}", + howpublished="RFC 4920 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4920", + pages="1--38", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4920.txt", + key="RFC 4920", + abstract={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. 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 detou rs 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]}, + keywords="multiprotocol label switching, generalized multiprotocol label switching, traffic engineered, te, lsp, label switched path", + doi="10.17487/RFC4920", + } + +@misc{rfc4923, + author="F. Baker and P. Bose", + title="{Quality of Service (QoS) Signaling in a Nested Virtual Private Network}", + howpublished="RFC 4923 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4923", + pages="1--38", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4923.txt", + key="RFC 4923", + abstract={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.}, + keywords="vpn, nested vpn, integrated services", + doi="10.17487/RFC4923", + } + +@misc{rfc4924, + author="B. {Aboba (Ed.)} and E. Davies", + title="{Reflections on Internet Transparency}", + howpublished="RFC 4924 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4924", + pages="1--15", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4924.txt", + key="RFC 4924", + abstract={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.}, + doi="10.17487/RFC4924", + } + +@misc{rfc4925, + author="X. {Li (Ed.)} and S. {Dawkins (Ed.)} and D. {Ward (Ed.)} and A. {Durand (Ed.)}", + title="{Softwire Problem Statement}", + howpublished="RFC 4925 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4925", + pages="1--23", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4925.txt", + key="RFC 4925", + abstract={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.}, + doi="10.17487/RFC4925", + } + +@misc{rfc4926, + author="T.Kalin and M.Molina", + title="{A URN Namespace for GEANT}", + howpublished="RFC 4926 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4926", + pages="1--9", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4926.txt", + key="RFC 4926", + abstract={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.}, + keywords="uniform resource name, dante", + doi="10.17487/RFC4926", + } + +@misc{rfc4927, + author="J.-L. Le {Roux (Ed.)}", + title="{Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering}", + howpublished="RFC 4927 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4927", + pages="1--12", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4927.txt", + key="RFC 4927", + abstract={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.}, + keywords="gmpls, te-lsp, traffic engineered label switched path, pce, path computation element", + doi="10.17487/RFC4927", + } + +@misc{rfc4928, + author="G. Swallow and S. Bryant and L. Andersson", + title="{Avoiding Equal Cost Multipath Treatment in MPLS Networks}", + howpublished="RFC 4928 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4928", + pages="1--8", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7274", +url="https://www.rfc-editor.org/rfc/rfc4928.txt", + key="RFC 4928", + abstract={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.}, + keywords="ecmp", + doi="10.17487/RFC4928", + } + +@misc{rfc4929, + author="L. {Andersson (Ed.)} and A. {Farrel (Ed.)}", + title="{Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures}", + howpublished="RFC 4929 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4929", + pages="1--23", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4929.txt", + key="RFC 4929", + abstract={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.}, + keywords="", + doi="10.17487/RFC4929", + } + +@misc{rfc4930, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 4930 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4930", + pages="1--72", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5730", +url="https://www.rfc-editor.org/rfc/rfc4930.txt", + key="RFC 4930", + abstract={This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730. [STANDARDS-TRACK]}, + keywords="shared framework mapping", + doi="10.17487/RFC4930", + } + +@misc{rfc4931, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Domain Name Mapping}", + howpublished="RFC 4931 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4931", + pages="1--46", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5731", +url="https://www.rfc-editor.org/rfc/rfc4931.txt", + key="RFC 4931", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 3731. [STANDARDS-TRACK]}, + keywords="syntax, semantics", + doi="10.17487/RFC4931", + } + +@misc{rfc4932, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Host Mapping}", + howpublished="RFC 4932 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4932", + pages="1--30", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5732", +url="https://www.rfc-editor.org/rfc/rfc4932.txt", + key="RFC 4932", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732. [STANDARDS-TRACK]}, + keywords="syntax, semantics", + doi="10.17487/RFC4932", + } + +@misc{rfc4933, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Contact Mapping}", + howpublished="RFC 4933 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4933", + pages="1--43", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5733", +url="https://www.rfc-editor.org/rfc/rfc4933.txt", + key="RFC 4933", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ``contacts'') stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733. [STANDARDS-TRACK]}, + keywords="syntax, semantics", + doi="10.17487/RFC4933", + } + +@misc{rfc4934, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Transport Over TCP}", + howpublished="RFC 4934 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4934", + pages="1--10", + year=2007, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5734", +url="https://www.rfc-editor.org/rfc/rfc4934.txt", + key="RFC 4934", + abstract={This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734. [STANDARDS-TRACK]}, + keywords="mapping, client, server, tls, transport layer security", + doi="10.17487/RFC4934", + } + +@misc{rfc4935, + author="C. DeSanti and H.K. Vivek and K. McCloghrie and S. Gai", + title="{Fibre Channel Fabric Configuration Server MIB}", + howpublished="RFC 4935 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4935", + pages="1--50", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4935.txt", + key="RFC 4935", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. [STANDARDS-TRACK]}, + keywords="management information base, T11-FC-FABRIC-CONFIG-SERVER-MIB", + doi="10.17487/RFC4935", + } + +@misc{rfc4936, + author="C. DeSanti and H.K. Vivek and K. McCloghrie and S. Gai", + title="{Fibre Channel Zone Server MIB}", + howpublished="RFC 4936 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4936", + pages="1--84", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4936.txt", + key="RFC 4936", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. [STANDARDS-TRACK]}, + keywords="management information base, T11-FC-FABRIC-LOCK-MIB, T11-FC-ZONE-SERVER-MIB", + doi="10.17487/RFC4936", + } + +@misc{rfc4937, + author="P. Arberg and V. Mammoliti", + title="{IANA Considerations for PPP over Ethernet (PPPoE)}", + howpublished="RFC 4937 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4937", + pages="1--6", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4937.txt", + key="RFC 4937", + abstract={This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. This memo provides information for the Internet community.}, + doi="10.17487/RFC4937", + } + +@misc{rfc4938, + author="B. Berry and H. Holgate", + title="{PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics}", + howpublished="RFC 4938 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4938", + pages="1--17", + year=2007, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5578", +url="https://www.rfc-editor.org/rfc/rfc4938.txt", + key="RFC 4938", + abstract={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.}, + doi="10.17487/RFC4938", + } + +@misc{rfc4939, + author="K. Gibbons and G. Ramkumar and S. Kipp", + title="{Definitions of Managed Objects for iSNS (Internet Storage Name Service)}", + howpublished="RFC 4939 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4939", + pages="1--80", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4939.txt", + key="RFC 4939", + abstract={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]}, + keywords="mib, management information base, iscsi, internet small computer system interface, ifcp, internet fibre channel protocol, ISNS-MIB", + doi="10.17487/RFC4939", + } + +@misc{rfc4940, + author="K. Kompella and B. Fenner", + title="{IANA Considerations for OSPF}", + howpublished="RFC 4940 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4940", + pages="1--15", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4940.txt", + key="RFC 4940", + abstract={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.}, + keywords="open shortest path first", + doi="10.17487/RFC4940", + } + +@misc{rfc4941, + author="T. Narten and R. Draves and S. Krishnan", + title="{Privacy Extensions for Stateless Address Autoconfiguration in IPv6}", + howpublished="RFC 4941 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="4941", + pages="1--23", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4941.txt", + key="RFC 4941", + abstract={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]}, + keywords="privacy, anonymity, unlinkability, crypto-based address changing", + doi="10.17487/RFC4941", + } + +@misc{rfc4942, + author="E. Davies and S. Krishnan and P. Savola", + title="{IPv6 Transition/Co-existence Security Considerations}", + howpublished="RFC 4942 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4942", + pages="1--41", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4942.txt", + key="RFC 4942", + abstract={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: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. This memo provides information for the Internet community.}, + keywords="internet protocol version 6, dual-protocol network, ipv4", + doi="10.17487/RFC4942", + } + +@misc{rfc4943, + author="S. Roy and A. Durand and J. Paugh", + title="{IPv6 Neighbor Discovery On-Link Assumption Considered Harmful}", + howpublished="RFC 4943 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4943", + pages="1--8", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4943.txt", + key="RFC 4943", + abstract={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.}, + keywords="internet protocol version 6", + doi="10.17487/RFC4943", + } + +@misc{rfc4944, + author="G. Montenegro and N. Kushalnagar and J. Hui and D. Culler", + title="{Transmission of IPv6 Packets over IEEE 802.15.4 Networks}", + howpublished="RFC 4944 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4944", + pages="1--30", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6282, 6775, 8025, 8066", +url="https://www.rfc-editor.org/rfc/rfc4944.txt", + key="RFC 4944", + abstract={This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on 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]}, + keywords="internet protocol version 6, link-local address, stateless autoconfiguration", + doi="10.17487/RFC4944", + } + +@misc{rfc4945, + author="B. Korver", + title="{The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX}", + howpublished="RFC 4945 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4945", + pages="1--43", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4945.txt", + key="RFC 4945", + abstract={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]}, + keywords="internet key exchange, public key infrastructure for x.509, ipsec", + doi="10.17487/RFC4945", + } + +@misc{rfc4946, + author="J. Snell", + title="{Atom License Extension}", + howpublished="RFC 4946 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4946", + pages="1--8", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4946.txt", + key="RFC 4946", + abstract={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.}, + keywords="atom syndication format, atom feeds, atom entries", + doi="10.17487/RFC4946", + } + +@misc{rfc4947, + author="G. Fairhurst and M. Montpetit", + title="{Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks}", + howpublished="RFC 4947 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4947", + pages="1--41", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4947.txt", + key="RFC 4947", + abstract={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. 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.}, + keywords="encapsulate, motion picture experts group, unidirectional link protocol, UniDirectional Link Routing, address resolution protocol", + doi="10.17487/RFC4947", + } + +@misc{rfc4948, + author="L. Andersson and E. Davies and L. Zhang", + title="{Report from the IAB workshop on Unwanted Traffic March 9-10, 2006}", + howpublished="RFC 4948 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4948", + pages="1--43", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4948.txt", + key="RFC 4948", + abstract={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.}, + keywords="spam, botnet", + doi="10.17487/RFC4948", + } + +@misc{rfc4949, + author="R. Shirey", + title="{Internet Security Glossary, Version 2}", + howpublished="RFC 4949 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4949", + pages="1--365", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4949.txt", + key="RFC 4949", + abstract={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.}, + keywords="abbreviation, clarity, definition, dictionary, language, punctuation, synonym, terminology, writing", + doi="10.17487/RFC4949", + } + +@misc{rfc4950, + author="R. Bonica and D. Gan and D. Tappan and C. Pignataro", + title="{ICMP Extensions for Multiprotocol Label Switching}", + howpublished="RFC 4950 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4950", + pages="1--8", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4950.txt", + key="RFC 4950", + abstract={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]}, + keywords="Internet Control Message Protocol", + doi="10.17487/RFC4950", + } + +@misc{rfc4951, + author="V. {Jain (Ed.)}", + title="{Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) ``failover''}", + howpublished="RFC 4951 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4951", + pages="1--26", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4951.txt", + key="RFC 4951", + abstract={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]}, + keywords="control connection, layer 2 connectivity", + doi="10.17487/RFC4951", + } + +@misc{rfc4952, + author="J. Klensin and Y. Ko", + title="{Overview and Framework for Internationalized Email}", + howpublished="RFC 4952 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4952", + pages="1--20", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6530, updated by RFC 5336", +url="https://www.rfc-editor.org/rfc/rfc4952.txt", + key="RFC 4952", + abstract={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.}, + keywords="smtp", + doi="10.17487/RFC4952", + } + +@misc{rfc4953, + author="J. Touch", + title="{Defending TCP Against Spoofing Attacks}", + howpublished="RFC 4953 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4953", + pages="1--28", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4953.txt", + key="RFC 4953", + abstract={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, discussin g 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.}, + keywords="rst, transport control protocol", + doi="10.17487/RFC4953", + } + +@misc{rfc4954, + author="R. {Siemborski (Ed.)} and A. {Melnikov (Ed.)}", + title="{SMTP Service Extension for Authentication}", + howpublished="RFC 4954 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4954", + pages="1--20", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5248", +url="https://www.rfc-editor.org/rfc/rfc4954.txt", + key="RFC 4954", + abstract={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. This document obsoletes RFC 2554. [STANDARDS-TRACK]}, + keywords="simple mail transport protocol, security layer, sasl", + doi="10.17487/RFC4954", + } + +@misc{rfc4955, + author="D. Blacka", + title="{DNS Security (DNSSEC) Experiments}", + howpublished="RFC 4955 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4955", + pages="1--7", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4955.txt", + key="RFC 4955", + abstract={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]}, + keywords="domain namespace", + doi="10.17487/RFC4955", + } + +@misc{rfc4956, + author="R. Arends and M. Kosters and D. Blacka", + title="{DNS Security (DNSSEC) Opt-In}", + howpublished="RFC 4956 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4956", + pages="1--17", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4956.txt", + key="RFC 4956", + abstract={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.}, + keywords="domain namespace", + doi="10.17487/RFC4956", + } + +@misc{rfc4957, + author="S. {Krishnan (Ed.)} and N. Montavont and E. Njedjou and S. Veerepalli and A. {Yegin (Ed.)}", + title="{Link-Layer Event Notifications for Detecting Network Attachments}", + howpublished="RFC 4957 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4957", + pages="1--18", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4957.txt", + key="RFC 4957", + abstract={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.}, + doi="10.17487/RFC4957", + } + +@misc{rfc4958, + author="K. Carlberg", + title="{A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain}", + howpublished="RFC 4958 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4958", + pages="1--28", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4958.txt", + key="RFC 4958", + abstract={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.}, + keywords="priority, prioritization, preferential service", + doi="10.17487/RFC4958", + } + +@misc{rfc4959, + author="R. Siemborski and A. Gulbrandsen", + title="{IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response}", + howpublished="RFC 4959 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4959", + pages="1--7", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4959.txt", + key="RFC 4959", + abstract={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. 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]}, + keywords="imap authenticate, internet message access protocol", + doi="10.17487/RFC4959", + } + +@misc{rfc4960, + author="R. {Stewart (Ed.)}", + title="{Stream Control Transmission Protocol}", + howpublished="RFC 4960 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4960", + pages="1--152", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6096, 6335, 7053", +url="https://www.rfc-editor.org/rfc/rfc4960.txt", + key="RFC 4960", + abstract={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. 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: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STAN DARDS-TRACK]}, + keywords="SCTP, IP, internet, transport, packet, network", + doi="10.17487/RFC4960", + } + +@misc{rfc4961, + author="D. Wing", + title="{Symmetric RTP / RTP Control Protocol (RTCP)}", + howpublished="RFC 4961 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4961", + pages="1--6", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4961.txt", + key="RFC 4961", + abstract={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.}, + keywords="real time transport protocol, symmetric rtcp", + doi="10.17487/RFC4961", + } + +@misc{rfc4962, + author="R. Housley and B. Aboba", + title="{Guidance for Authentication, Authorization, and Accounting (AAA) Key Management}", + howpublished="RFC 4962 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="4962", + pages="1--23", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4962.txt", + key="RFC 4962", + abstract={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.}, + keywords="", + doi="10.17487/RFC4962", + } + +@misc{rfc4963, + author="J. Heffner and M. Mathis and B. Chandler", + title="{IPv4 Reassembly Errors at High Data Rates}", + howpublished="RFC 4963 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4963", + pages="1--10", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4963.txt", + key="RFC 4963", + abstract={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.}, + doi="10.17487/RFC4963", + } + +@misc{rfc4964, + author="A. {Allen (Ed.)} and J. Holm and T. Hallin", + title="{The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular}", + howpublished="RFC 4964 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4964", + pages="1--32", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4964.txt", + key="RFC 4964", + abstract={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.}, + keywords="p-header, oma, open mobile alliance, poc", + doi="10.17487/RFC4964", + } + +@misc{rfc4965, + author="J-F. Mule and W. Townsley", + title="{CableLabs - IETF Standardization Collaboration}", + howpublished="RFC 4965 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4965", + pages="1--10", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4965.txt", + key="RFC 4965", + abstract={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.}, + keywords="IETF CableLabs Collaboration, liaison, Cable Television Laboratories, DOCSIS, PacketCable, OpenCable", + doi="10.17487/RFC4965", + } + +@misc{rfc4966, + author="C. Aoun and E. Davies", + title="{Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status}", + howpublished="RFC 4966 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4966", + pages="1--25", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4966.txt", + key="RFC 4966", + abstract={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.}, + keywords="NAT-PT, v6ops", + doi="10.17487/RFC4966", + } + +@misc{rfc4967, + author="B. Rosen", + title="{Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier}", + howpublished="RFC 4967 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4967", + pages="1--6", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4967.txt", + key="RFC 4967", + abstract={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]}, + keywords="dialstring", + doi="10.17487/RFC4967", + } + +@misc{rfc4968, + author="S. {Madanapalli (Ed.)}", + title="{Analysis of IPv6 Link Models for 802.16 Based Networks}", + howpublished="RFC 4968 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4968", + pages="1--16", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4968.txt", + key="RFC 4968", + abstract={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.}, + keywords="wimax", + doi="10.17487/RFC4968", + } + +@misc{rfc4969, + author="A. Mayrhofer", + title="{IANA Registration for vCard Enumservice}", + howpublished="RFC 4969 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4969", + pages="1--7", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4969.txt", + key="RFC 4969", + abstract={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. 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]}, + keywords="enum, e.164", + doi="10.17487/RFC4969", + } + +@misc{rfc4970, + author="A. {Lindem (Ed.)} and N. Shen and JP. Vasseur and R. Aggarwal and S. Shaffer", + title="{Extensions to OSPF for Advertising Optional Router Capabilities}", + howpublished="RFC 4970 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4970", + pages="1--13", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7770", +url="https://www.rfc-editor.org/rfc/rfc4970.txt", + key="RFC 4970", + abstract={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]}, + keywords="ospfv2, ospfv3, open shortest path first, ri, router information, lsa, link state advertisement", + doi="10.17487/RFC4970", + } + +@misc{rfc4971, + author="JP. {Vasseur (Ed.)} and N. {Shen (Ed.)} and R. {Aggarwal (Ed.)}", + title="{Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information}", + howpublished="RFC 4971 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4971", + pages="1--9", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7981", +url="https://www.rfc-editor.org/rfc/rfc4971.txt", + key="RFC 4971", + abstract={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]}, + keywords="capabilty", + doi="10.17487/RFC4971", + } + +@misc{rfc4972, + author="JP. {Vasseur (Ed.)} and JL. {Leroux (Ed.)} and S. Yasukawa and S. Previdi and P. Psenak and P. Mabbey", + title="{Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership}", + howpublished="RFC 4972 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4972", + pages="1--15", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4972.txt", + key="RFC 4972", + abstract={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]}, + keywords="mpls-te, lsp, label switched path, igp, is-is, ospf", + doi="10.17487/RFC4972", + } + +@misc{rfc4973, + author="P. Srisuresh and P. Joseph", + title="{OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering}", + howpublished="RFC 4973 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4973", + pages="1--50", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4973.txt", + key="RFC 4973", + abstract={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.}, + keywords="ospf-te, link state advertisement, lsa", + doi="10.17487/RFC4973", + } + +@misc{rfc4974, + author="D. Papadimitriou and A. Farrel", + title="{Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls}", + howpublished="RFC 4974 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4974", + pages="1--31", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6001", +url="https://www.rfc-editor.org/rfc/rfc4974.txt", + key="RFC 4974", + abstract={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. 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). 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. 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]}, + keywords="", + doi="10.17487/RFC4974", + } + +@misc{rfc4975, + author="B. {Campbell (Ed.)} and R. {Mahy (Ed.)} and C. {Jennings (Ed.)}", + title="{The Message Session Relay Protocol (MSRP)}", + howpublished="RFC 4975 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4975", + pages="1--63", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7977", +url="https://www.rfc-editor.org/rfc/rfc4975.txt", + key="RFC 4975", + abstract={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]}, + keywords="instant message", + doi="10.17487/RFC4975", + } + +@misc{rfc4976, + author="C. Jennings and R. Mahy and A. B. Roach", + title="{Relay Extensions for the Message Sessions Relay Protocol (MSRP)}", + howpublished="RFC 4976 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4976", + pages="1--36", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7977", +url="https://www.rfc-editor.org/rfc/rfc4976.txt", + key="RFC 4976", + abstract={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]}, + keywords="instante message, page-mode, session-mode, relay intermediary", + doi="10.17487/RFC4976", + } + +@misc{rfc4977, + author="G. Tsirtsis and H. Soliman", + title="{Problem Statement: Dual Stack Mobility}", + howpublished="RFC 4977 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4977", + pages="1--8", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4977.txt", + key="RFC 4977", + abstract={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.}, + keywords="mobility management protocol, mipv4, mipv6, mobile ip", + doi="10.17487/RFC4977", + } + +@misc{rfc4978, + author="A. Gulbrandsen", + title="{The IMAP COMPRESS Extension}", + howpublished="RFC 4978 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4978", + pages="1--9", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4978.txt", + key="RFC 4978", + abstract={The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK]}, + keywords="Internet Message Access Protocol", + doi="10.17487/RFC4978", + } + +@misc{rfc4979, + author="A. Mayrhofer", + title="{IANA Registration for Enumservice 'XMPP'}", + howpublished="RFC 4979 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4979", + pages="1--7", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc4979.txt", + key="RFC 4979", + abstract={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]}, + keywords="extensible messaging and presence protocol, e.164", + doi="10.17487/RFC4979", + } + +@misc{rfc4980, + author="C. Ng and T. Ernst and E. Paik and M. Bagnulo", + title="{Analysis of Multihoming in Network Mobility Support}", + howpublished="RFC 4980 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4980", + pages="1--39", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4980.txt", + key="RFC 4980", + abstract={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.}, + keywords="nemo, ipv6, mobile networks", + doi="10.17487/RFC4980", + } + +@misc{rfc4981, + author="J. Risson and T. Moors", + title="{Survey of Research towards Robust Peer-to-Peer Networks: Search Methods}", + howpublished="RFC 4981 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4981", + pages="1--91", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4981.txt", + key="RFC 4981", + abstract={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. 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. 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.}, + keywords="Peer-to-peer network, Distributed hash table, Structured overlay, Unstructured overlay, Key-based routing, Consistent hashing, Scalable distributed data structure, Dependability, Hypercube, Plaxton tree, de Bruijn graph, Skip graph, Torus, Butterfly network, Vector model, Latent semantic indexing", + doi="10.17487/RFC4981", + } + +@misc{rfc4982, + author="M. Bagnulo and J. Arkko", + title="{Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)}", + howpublished="RFC 4982 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4982", + pages="1--9", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4982.txt", + key="RFC 4982", + abstract={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]}, + keywords="", + doi="10.17487/RFC4982", + } + +@misc{rfc4983, + author="C. DeSanti and H.K. Vivek and K. McCloghrie and S. Gai", + title="{Fibre Channel Registered State Change Notification (RSCN) MIB}", + howpublished="RFC 4983 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4983", + pages="1--28", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4983.txt", + key="RFC 4983", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). [STANDARDS-TRACK]}, + keywords="management information base, T11-FC-RSCN-MIB", + doi="10.17487/RFC4983", + } + +@misc{rfc4984, + author="D. {Meyer (Ed.)} and L. {Zhang (Ed.)} and K. {Fall (Ed.)}", + title="{Report from the IAB Workshop on Routing and Addressing}", + howpublished="RFC 4984 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4984", + pages="1--39", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4984.txt", + key="RFC 4984", + abstract={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. 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.}, + keywords="routing and addressing workshop, routing table growth, addressing architecture", + doi="10.17487/RFC4984", + } + +@misc{rfc4985, + author="S. Santesson", + title="{Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name}", + howpublished="RFC 4985 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4985", + pages="1--10", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4985.txt", + key="RFC 4985", + abstract={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]}, + keywords="othername", + doi="10.17487/RFC4985", + } + +@misc{rfc4986, + author="H. Eland and R. Mundy and S. Crocker and S. Krishnaswamy", + title="{Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover}", + howpublished="RFC 4986 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4986", + pages="1--11", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4986.txt", + key="RFC 4986", + abstract={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.}, + keywords="dns signed zone", + doi="10.17487/RFC4986", + } + +@misc{rfc4987, + author="W. Eddy", + title="{TCP SYN Flooding Attacks and Common Mitigations}", + howpublished="RFC 4987 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4987", + pages="1--19", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4987.txt", + key="RFC 4987", + abstract={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.}, + keywords="TCP SYN Flood, TCP SYN Cookies, denial-of-service, DoS", + doi="10.17487/RFC4987", + } + +@misc{rfc4988, + author="R. Koodli and C. Perkins", + title="{Mobile IPv4 Fast Handovers}", + howpublished="RFC 4988 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="4988", + pages="1--28", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4988.txt", + key="RFC 4988", + abstract={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.}, + keywords="mip4, delay, packet loss, movement detection, ip address configuration, loation update latency, care-of address, care of address, coa", + doi="10.17487/RFC4988", + } + +@misc{rfc4990, + author="K. Shiomoto and R. Papneja and R. Rabbat", + title="{Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks}", + howpublished="RFC 4990 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="4990", + pages="1--23", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4990.txt", + key="RFC 4990", + abstract={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. 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. 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.}, + keywords="address field, identifier field", + doi="10.17487/RFC4990", + } + +@misc{rfc4991, + author="A. Newton", + title="{A Common Schema for Internet Registry Information Service Transfer Protocols}", + howpublished="RFC 4991 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4991", + pages="1--13", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4991.txt", + key="RFC 4991", + abstract={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]}, + keywords="iris, xml", + doi="10.17487/RFC4991", + } + +@misc{rfc4992, + author="A. Newton", + title="{XML Pipelining with Chunks for the Internet Registry Information Service}", + howpublished="RFC 4992 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4992", + pages="1--29", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4992.txt", + key="RFC 4992", + abstract={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]}, + keywords="tcp, transport control protocol, iris", + doi="10.17487/RFC4992", + } + +@misc{rfc4993, + author="A. Newton", + title="{A Lightweight UDP Transfer Protocol for the Internet Registry Information Service}", + howpublished="RFC 4993 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4993", + pages="1--19", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4993.txt", + key="RFC 4993", + abstract={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]}, + keywords="iris", + doi="10.17487/RFC4993", + } + +@misc{rfc4994, + author="S. Zeng and B. Volz and K. Kinnear and J. Brzozowski", + title="{DHCPv6 Relay Agent Echo Request Option}", + howpublished="RFC 4994 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4994", + pages="1--6", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4994.txt", + key="RFC 4994", + abstract={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]}, + keywords="dynamic host configuration protocol, relay agent option", + doi="10.17487/RFC4994", + } + +@misc{rfc4995, + author="L-E. Jonsson and G. Pelletier and K. Sandlund", + title="{The RObust Header Compression (ROHC) Framework}", + howpublished="RFC 4995 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4995", + pages="1--40", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5795", +url="https://www.rfc-editor.org/rfc/rfc4995.txt", + key="RFC 4995", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC4995", + } + +@misc{rfc4996, + author="G. Pelletier and K. Sandlund and L-E. Jonsson and M. West", + title="{RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)}", + howpublished="RFC 4996 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4996", + pages="1--94", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6846", +url="https://www.rfc-editor.org/rfc/rfc4996.txt", + key="RFC 4996", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC4996", + } + +@misc{rfc4997, + author="R. Finking and G. Pelletier", + title="{Formal Notation for RObust Header Compression (ROHC-FN)}", + howpublished="RFC 4997 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4997", + pages="1--62", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4997.txt", + key="RFC 4997", + abstract={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]}, + keywords="Robust Header Compression - Formal Notation", + doi="10.17487/RFC4997", + } + +@misc{rfc4998, + author="T. Gondrom and R. Brandner and U. Pordesch", + title="{Evidence Record Syntax (ERS)}", + howpublished="RFC 4998 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="4998", + pages="1--32", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc4998.txt", + key="RFC 4998", + abstract={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]}, + keywords="long-term archive, security, timestamp, evidence record, archive timestamp", + doi="10.17487/RFC4998", + } + +@misc{rfc5000, + author="RFC Editor", + title="{Internet Official Protocol Standards}", + howpublished="RFC 5000 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5000", + pages="1--75", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7100", +url="https://www.rfc-editor.org/rfc/rfc5000.txt", + key="RFC 5000", + abstract={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. For an up-to-date list, see https://www.rfc-editor.org/rfcxx00.html, which is updated daily. This memo provides information for the Internet community.}, + keywords="", + doi="10.17487/RFC5000", + } + +@misc{rfc5001, + author="R. Austein", + title="{DNS Name Server Identifier (NSID) Option}", + howpublished="RFC 5001 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5001", + pages="1--11", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5001.txt", + key="RFC 5001", + abstract={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]}, + keywords="domain name space, namespace", + doi="10.17487/RFC5001", + } + +@misc{rfc5002, + author="G. Camarillo and G. Blanco", + title="{The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)}", + howpublished="RFC 5002 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5002", + pages="1--7", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8217", +url="https://www.rfc-editor.org/rfc/rfc5002.txt", + key="RFC 5002", + abstract={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.}, + keywords="3gpp, ims, ip multimedia subsystem", + doi="10.17487/RFC5002", + } + +@misc{rfc5003, + author="C. Metz and L. Martini and F. Balus and J. Sugimoto", + title="{Attachment Individual Identifier (AII) Types for Aggregation}", + howpublished="RFC 5003 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5003", + pages="1--7", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5003.txt", + key="RFC 5003", + abstract={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]}, + keywords="tlv, pseudowire", + doi="10.17487/RFC5003", + } + +@misc{rfc5004, + author="E. Chen and S. Sangli", + title="{Avoid BGP Best Path Transitions from One External to Another}", + howpublished="RFC 5004 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5004", + pages="1--6", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5004.txt", + key="RFC 5004", + abstract={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]}, + keywords="border gateway protocol", + doi="10.17487/RFC5004", + } + +@misc{rfc5005, + author="M. Nottingham", + title="{Feed Paging and Archiving}", + howpublished="RFC 5005 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5005", + pages="1--15", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5005.txt", + key="RFC 5005", + abstract={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]}, + keywords="atom, rss", + doi="10.17487/RFC5005", + } + +@misc{rfc5006, + author="J. {Jeong (Ed.)} and S. Park and L. Beloeil and S. Madanapalli", + title="{IPv6 Router Advertisement Option for DNS Configuration}", + howpublished="RFC 5006 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5006", + pages="1--12", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6106", +url="https://www.rfc-editor.org/rfc/rfc5006.txt", + key="RFC 5006", + abstract={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.}, + keywords="domain namespace", + doi="10.17487/RFC5006", + } + +@misc{rfc5007, + author="J. Brzozowski and K. Kinnear and B. Volz and S. Zeng", + title="{DHCPv6 Leasequery}", + howpublished="RFC 5007 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5007", + pages="1--23", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5007.txt", + key="RFC 5007", + abstract={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]}, + keywords="dhc, dhcp, ipv6", + doi="10.17487/RFC5007", + } + +@misc{rfc5008, + author="R. Housley and J. Solinas", + title="{Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)}", + howpublished="RFC 5008 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5008", + pages="1--15", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6318", +url="https://www.rfc-editor.org/rfc/rfc5008.txt", + key="RFC 5008", + abstract={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.}, + keywords="nsa", + doi="10.17487/RFC5008", + } + +@misc{rfc5009, + author="R. Ejza", + title="{Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media}", + howpublished="RFC 5009 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5009", + pages="1--15", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5009.txt", + key="RFC 5009", + abstract={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.}, + keywords="IMS, NGN, ETSI TISPAN, Gating, Cut-through, Call progress, Charging, PSTN, Interworking, Gateway, Ringback, Trust domain", + doi="10.17487/RFC5009", + } + +@misc{rfc5010, + author="K. Kinnear and M. Normoyle and M. Stapp", + title="{The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption}", + howpublished="RFC 5010 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5010", + pages="1--7", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5010.txt", + key="RFC 5010", + abstract={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]}, + keywords="unicast flag, broadcast flag", + doi="10.17487/RFC5010", + } + +@misc{rfc5011, + author="M. StJohns", + title="{Automated Updates of DNS Security (DNSSEC) Trust Anchors}", + howpublished="RFC 5011 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5011", + pages="1--14", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5011.txt", + key="RFC 5011", + abstract={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). 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]}, + keywords="n-1 key, n keys", + doi="10.17487/RFC5011", + } + +@misc{rfc5012, + author="H. Schulzrinne and R. {Marshall (Ed.)}", + title="{Requirements for Emergency Context Resolution with Internet Technologies}", + howpublished="RFC 5012 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5012", + pages="1--23", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5012.txt", + key="RFC 5012", + abstract={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.}, + keywords="emergency calling, ecrit", + doi="10.17487/RFC5012", + } + +@misc{rfc5013, + author="J. Kunze and T. Baker", + title="{The Dublin Core Metadata Element Set}", + howpublished="RFC 5013 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5013", + pages="1--9", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5013.txt", + key="RFC 5013", + abstract={This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment. This memo provides information for the Internet community.}, + keywords="resource description, object descriptors, digital library collections", + doi="10.17487/RFC5013", + } + +@misc{rfc5014, + author="E. Nordmark and S. Chakrabarti and J. Laganier", + title="{IPv6 Socket API for Source Address Selection}", + howpublished="RFC 5014 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5014", + pages="1--24", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5014.txt", + key="RFC 5014", + abstract={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 fo r selecting Cryptographically Generated Address (CGA) or non-CGA source addresses. This memo provides information for the Internet community.}, + keywords="getaddrinfo()cga, cryptographically generated address", + doi="10.17487/RFC5014", + } + +@misc{rfc5015, + author="M. Handley and I. Kouvelas and T. Speakman and L. Vicisano", + title="{Bidirectional Protocol Independent Multicast (BIDIR-PIM)}", + howpublished="RFC 5015 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5015", + pages="1--43", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5015.txt", + key="RFC 5015", + abstract={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]}, + keywords="pim, sparse-mode, shared trees", + doi="10.17487/RFC5015", + } + +@misc{rfc5016, + author="M. Thomas", + title="{Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol}", + howpublished="RFC 5016 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5016", + pages="1--15", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5016.txt", + key="RFC 5016", + abstract={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.}, + keywords="cryptographic", + doi="10.17487/RFC5016", + } + +@misc{rfc5017, + author="D. {McWalter (Ed.)}", + title="{MIB Textual Conventions for Uniform Resource Identifiers (URIs)}", + howpublished="RFC 5017 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5017", + pages="1--7", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5017.txt", + key="RFC 5017", + abstract={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]}, + keywords="management information base, URI-TC-MIB", + doi="10.17487/RFC5017", + } + +@misc{rfc5018, + author="G. Camarillo", + title="{Connection Establishment in the Binary Floor Control Protocol (BFCP)}", + howpublished="RFC 5018 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5018", + pages="1--9", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5018.txt", + key="RFC 5018", + abstract={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]}, + keywords="floor control server, tls, transport layer security", + doi="10.17487/RFC5018", + } + +@misc{rfc5019, + author="A. Deacon and R. Hurst", + title="{The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments}", + howpublished="RFC 5019 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5019", + pages="1--22", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5019.txt", + key="RFC 5019", + abstract={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]}, + keywords="OCSP, Online Certificate, Status Protocol, certificate status, http caching, http proxies, efficient, cacheable, pre-produced", + doi="10.17487/RFC5019", + } + +@misc{rfc5020, + author="K. Zeilenga", + title="{The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute}", + howpublished="RFC 5020 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5020", + pages="1--5", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5020.txt", + key="RFC 5020", + abstract={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]}, + keywords="x.500", + doi="10.17487/RFC5020", + } + +@misc{rfc5021, + author="S. Josefsson", + title="{Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP}", + howpublished="RFC 5021 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5021", + pages="1--7", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5021.txt", + key="RFC 5021", + abstract={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]}, + keywords="", + doi="10.17487/RFC5021", + } + +@misc{rfc5022, + author="J. Van Dyke and E. {Burger (Ed.)} and A. Spitzer", + title="{Media Server Control Markup Language (MSCML) and Protocol}", + howpublished="RFC 5022 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5022", + pages="1--81", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5022.txt", + key="RFC 5022", + abstract={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.}, + keywords="sip, ivr, interactive voice response", + doi="10.17487/RFC5022", + } + +@misc{rfc5023, + author="J. {Gregorio (Ed.)} and B. de {hOra (Ed.)}", + title="{The Atom Publishing Protocol}", + howpublished="RFC 5023 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5023", + pages="1--53", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5023.txt", + key="RFC 5023", + abstract={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]}, + keywords="atompub, http transfer, atom syndication format", + doi="10.17487/RFC5023", + } + +@misc{rfc5024, + author="I. Friend", + title="{ODETTE File Transfer Protocol 2.0}", + howpublished="RFC 5024 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5024", + pages="1--135", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5024.txt", + key="RFC 5024", + abstract={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. 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. 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.}, + doi="10.17487/RFC5024", + } + +@misc{rfc5025, + author="J. Rosenberg", + title="{Presence Authorization Rules}", + howpublished="RFC 5025 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5025", + pages="1--28", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5025.txt", + key="RFC 5025", + abstract={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]}, + keywords="presence systems, authorization policies, xml, extensible markup language", + doi="10.17487/RFC5025", + } + +@misc{rfc5026, + author="G. {Giaretta (Ed.)} and J. Kempf and V. {Devarapalli (Ed.)}", + title="{Mobile IPv6 Bootstrapping in Split Scenario}", + howpublished="RFC 5026 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5026", + pages="1--28", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5026.txt", + key="RFC 5026", + abstract={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]}, + keywords="mip6, bootstrapping problem statement", + doi="10.17487/RFC5026", + } + +@misc{rfc5027, + author="F. Andreasen and D. Wing", + title="{Security Preconditions for Session Description Protocol (SDP) Media Streams}", + howpublished="RFC 5027 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5027", + pages="1--16", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5027.txt", + key="RFC 5027", + abstract={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]}, + keywords="DTLS, DTLS-SRTP, TLS, MIKEY, Security Descriptions, SRTP", + doi="10.17487/RFC5027", + } + +@misc{rfc5028, + author="R. Mahy", + title="{A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services}", + howpublished="RFC 5028 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5028", + pages="1--5", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc5028.txt", + key="RFC 5028", + abstract={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]}, + keywords="'im:', uri, uniform resource identifier", + doi="10.17487/RFC5028", + } + +@misc{rfc5029, + author="JP. Vasseur and S. Previdi", + title="{Definition of an IS-IS Link Attribute Sub-TLV}", + howpublished="RFC 5029 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5029", + pages="1--6", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5029.txt", + key="RFC 5029", + abstract={This document defines a sub-TLV called ``Link-attributes'' carried within the TLV 22 and used to flood some link characteristics. [STANDARDS-TRACK]}, + keywords="link-attributes, tlv 22", + doi="10.17487/RFC5029", + } + +@misc{rfc5030, + author="M. {Nakhjiri (Ed.)} and K. Chowdhury and A. Lior and K. Leung", + title="{Mobile IPv4 RADIUS Requirements}", + howpublished="RFC 5030 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5030", + pages="1--9", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5030.txt", + key="RFC 5030", + abstract={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.}, + keywords="remote authentication dial-in user service, mip, mipv4", + doi="10.17487/RFC5030", + } + +@misc{rfc5031, + author="H. Schulzrinne", + title="{A Uniform Resource Name (URN) for Emergency and Other Well-Known Services}", + howpublished="RFC 5031 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5031", + pages="1--14", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7163", +url="https://www.rfc-editor.org/rfc/rfc5031.txt", + key="RFC 5031", + abstract={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]}, + keywords="urn, ecrit", + doi="10.17487/RFC5031", + } + +@misc{rfc5032, + author="E. {Burger (Ed.)}", + title="{WITHIN Search Extension to the IMAP Protocol}", + howpublished="RFC 5032 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5032", + pages="1--5", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5032.txt", + key="RFC 5032", + abstract={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]}, + keywords="imap search, older, younger", + doi="10.17487/RFC5032", + } + +@misc{rfc5033, + author="S. Floyd and M. Allman", + title="{Specifying New Congestion Control Algorithms}", + howpublished="RFC 5033 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5033", + pages="1--10", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5033.txt", + key="RFC 5033", + abstract={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.}, + keywords="", + doi="10.17487/RFC5033", + } + +@misc{rfc5034, + author="R. Siemborski and A. Menon-Sen", + title="{The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism}", + howpublished="RFC 5034 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5034", + pages="1--12", + year=2007, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5034.txt", + key="RFC 5034", + abstract={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. 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]}, + keywords="POP3-AUTH, Post, Office, Protocol, Email", + doi="10.17487/RFC5034", + } + +@misc{rfc5035, + author="J. Schaad", + title="{Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility}", + howpublished="RFC 5035 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5035", + pages="1--17", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5035.txt", + key="RFC 5035", + abstract={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]}, + keywords="validation, signature, certificate", + doi="10.17487/RFC5035", + } + +@misc{rfc5036, + author="L. {Andersson (Ed.)} and I. {Minei (Ed.)} and B. {Thomas (Ed.)}", + title="{LDP Specification}", + howpublished="RFC 5036 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5036", + pages="1--135", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6720, 6790, 7358, 7552", +url="https://www.rfc-editor.org/rfc/rfc5036.txt", + key="RFC 5036", + abstract={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]}, + keywords="label, distribution, protocol", + doi="10.17487/RFC5036", + } + +@misc{rfc5037, + author="L. {Andersson (Ed.)} and I. {Minei (Ed.)} and B. {Thomas (Ed.)}", + title="{Experience with the Label Distribution Protocol (LDP)}", + howpublished="RFC 5037 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5037", + pages="1--7", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5037.txt", + key="RFC 5037", + abstract={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.}, + doi="10.17487/RFC5037", + } + +@misc{rfc5038, + author="B. Thomas and L. Andersson", + title="{The Label Distribution Protocol (LDP) Implementation Survey Results}", + howpublished="RFC 5038 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5038", + pages="1--23", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5038.txt", + key="RFC 5038", + abstract={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.}, + keywords="multiprotocol label switching, mpls, lsr, label switched routers", + doi="10.17487/RFC5038", + } + +@misc{rfc5039, + author="J. Rosenberg and C. Jennings", + title="{The Session Initiation Protocol (SIP) and Spam}", + howpublished="RFC 5039 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5039", + pages="1--28", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5039.txt", + key="RFC 5039", + abstract={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.}, + doi="10.17487/RFC5039", + } + +@misc{rfc5040, + author="R. Recio and B. Metzler and P. Culley and J. Hilland and D. Garcia", + title="{A Remote Direct Memory Access Protocol Specification}", + howpublished="RFC 5040 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5040", + pages="1--66", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc5040.txt", + key="RFC 5040", + abstract={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]}, + keywords="rdmap, ddp, direct data placement protocol", + doi="10.17487/RFC5040", + } + +@misc{rfc5041, + author="H. Shah and J. Pinkerton and R. Recio and P. Culley", + title="{Direct Data Placement over Reliable Transports}", + howpublished="RFC 5041 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5041", + pages="1--38", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc5041.txt", + key="RFC 5041", + abstract={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]}, + keywords="ddp, cpu", + doi="10.17487/RFC5041", + } + +@misc{rfc5042, + author="J. Pinkerton and E. Deleganes", + title="{Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security}", + howpublished="RFC 5042 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5042", + pages="1--52", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc5042.txt", + key="RFC 5042", + abstract={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]}, + keywords="rdma network interface card, rnic", + doi="10.17487/RFC5042", + } + +@misc{rfc5043, + author="C. {Bestler (Ed.)} and R. {Stewart (Ed.)}", + title="{Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation}", + howpublished="RFC 5043 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5043", + pages="1--18", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6581, 7146", +url="https://www.rfc-editor.org/rfc/rfc5043.txt", + key="RFC 5043", + abstract={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]}, + keywords="lower layer protocol, llp", + doi="10.17487/RFC5043", + } + +@misc{rfc5044, + author="P. Culley and U. Elzur and R. Recio and S. Bailey and J. Carrier", + title="{Marker PDU Aligned Framing for TCP Specification}", + howpublished="RFC 5044 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5044", + pages="1--74", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6581, 7146", +url="https://www.rfc-editor.org/rfc/rfc5044.txt", + key="RFC 5044", + abstract={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]}, + keywords="mpa, adaaptation layer, ddp, direct data placement protocol, transmission", + doi="10.17487/RFC5044", + } + +@misc{rfc5045, + author="C. {Bestler (Ed.)} and L. Coene", + title="{Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)}", + howpublished="RFC 5045 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5045", + pages="1--22", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc5045.txt", + key="RFC 5045", + abstract={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.}, + keywords="rdmap", + doi="10.17487/RFC5045", + } + +@misc{rfc5046, + author="M. Ko and M. Chadalapaka and J. Hufferd and U. Elzur and H. Shah and P. Thaler", + title="{Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)}", + howpublished="RFC 5046 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5046", + pages="1--85", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7145, updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc5046.txt", + key="RFC 5046", + abstract={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]}, + keywords="rdma data transfer", + doi="10.17487/RFC5046", + } + +@misc{rfc5047, + author="M. Chadalapaka and J. Hufferd and J. Satran and H. Shah", + title="{DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)}", + howpublished="RFC 5047 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5047", + pages="1--49", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc5047.txt", + key="RFC 5047", + abstract={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 la yer 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.}, + keywords="scsi transport protocol, tcp/ip", + doi="10.17487/RFC5047", + } + +@misc{rfc5048, + author="M. {Chadalapaka (Ed.)}", + title="{Internet Small Computer System Interface (iSCSI) Corrections and Clarifications}", + howpublished="RFC 5048 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5048", + pages="1--38", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7143, updated by RFC 7146", +url="https://www.rfc-editor.org/rfc/rfc5048.txt", + key="RFC 5048", + abstract={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]}, + keywords="scsi, iscsi protocol", + doi="10.17487/RFC5048", + } + +@misc{rfc5049, + author="C. Bormann and Z. Liu and R. Price and G. {Camarillo (Ed.)}", + title="{Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)}", + howpublished="RFC 5049 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5049", + pages="1--21", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5049.txt", + key="RFC 5049", + abstract={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]}, + keywords="", + doi="10.17487/RFC5049", + } + +@misc{rfc5050, + author="K. Scott and S. Burleigh", + title="{Bundle Protocol Specification}", + howpublished="RFC 5050 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5050", + pages="1--50", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5050.txt", + key="RFC 5050", + abstract={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). 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.}, + keywords="delay tolerant networking, dtn, dtnrg, exchange of messages", + doi="10.17487/RFC5050", + } + +@misc{rfc5051, + author="M. Crispin", + title="{i;unicode-casemap - Simple Unicode Collation Algorithm}", + howpublished="RFC 5051 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5051", + pages="1--7", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5051.txt", + key="RFC 5051", + abstract={This document describes ``i;unicode-casemap'', a simple case-insensitive collation for Unicode strings. It provides equality, substring, and ordering operations. [STANDARDS-TRACK]}, + keywords="unicode strings, i;ascii-casemap", + doi="10.17487/RFC5051", + } + +@misc{rfc5052, + author="M. Watson and M. Luby and L. Vicisano", + title="{Forward Error Correction (FEC) Building Block}", + howpublished="RFC 5052 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5052", + pages="1--25", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5052.txt", + key="RFC 5052", + abstract={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]}, + keywords="bulk data transfer", + doi="10.17487/RFC5052", + } + +@misc{rfc5053, + author="M. Luby and A. Shokrollahi and M. Watson and T. Stockhammer", + title="{Raptor Forward Error Correction Scheme for Object Delivery}", + howpublished="RFC 5053 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5053", + pages="1--46", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5053.txt", + key="RFC 5053", + abstract={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. 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. 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]}, + keywords="fec, fec encoding, raptor code", + doi="10.17487/RFC5053", + } + +@misc{rfc5054, + author="D. Taylor and T. Wu and N. Mavrogiannopoulos and T. Perrin", + title="{Using the Secure Remote Password (SRP) Protocol for TLS Authentication}", + howpublished="RFC 5054 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5054", + pages="1--24", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5054.txt", + key="RFC 5054", + abstract={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.}, + keywords="secure remote password protocol, transport layer security", + doi="10.17487/RFC5054", + } + +@misc{rfc5055, + author="T. Freeman and R. Housley and A. Malpani and D. Cooper and W. Polk", + title="{Server-Based Certificate Validation Protocol (SCVP)}", + howpublished="RFC 5055 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5055", + pages="1--88", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5055.txt", + key="RFC 5055", + abstract={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]}, + keywords="certification path construction, certification path validation", + doi="10.17487/RFC5055", + } + +@misc{rfc5056, + author="N. Williams", + title="{On the Use of Channel Bindings to Secure Channels}", + howpublished="RFC 5056 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5056", + pages="1--23", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5056.txt", + key="RFC 5056", + abstract={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. This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5056", + } + +@misc{rfc5057, + author="R. Sparks", + title="{Multiple Dialog Usages in the Session Initiation Protocol}", + howpublished="RFC 5057 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5057", + pages="1--26", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5057.txt", + key="RFC 5057", + abstract={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. 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. This is an informative document and makes no normative statements of any kind. This memo provides information for the Internet community.}, + doi="10.17487/RFC5057", + } + +@misc{rfc5058, + author="R. Boivie and N. Feldman and Y. Imai and W. Livens and D. Ooms", + title="{Explicit Multicast (Xcast) Concepts and Options}", + howpublished="RFC 5058 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5058", + pages="1--35", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5058.txt", + key="RFC 5058", + abstract={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. 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.}, + keywords="explicit multi-unicast", + doi="10.17487/RFC5058", + } + +@misc{rfc5059, + author="N. Bhaskar and A. Gall and J. Lingard and S. Venaas", + title="{Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)}", + howpublished="RFC 5059 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5059", + pages="1--42", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5059.txt", + key="RFC 5059", + abstract={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]}, + keywords="rendezvous point, rp, multicast router", + doi="10.17487/RFC5059", + } + +@misc{rfc5060, + author="R. Sivaramu and J. Lingard and D. McWalter and B. Joshi and A. Kessler", + title="{Protocol Independent Multicast MIB}", + howpublished="RFC 5060 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5060", + pages="1--90", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5060.txt", + key="RFC 5060", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) 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]}, + keywords="PIM, PIM-SM, BIDIR-PIM, PIM-DM, Multicast Routing, PIM-STD-MIB, management information base", + doi="10.17487/RFC5060", + } + +@misc{rfc5061, + author="R. Stewart and Q. Xie and M. Tuexen and S. Maruyama and M. Kozuka", + title="{Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration}", + howpublished="RFC 5061 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5061", + pages="1--41", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5061.txt", + key="RFC 5061", + abstract={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]}, + keywords="", + doi="10.17487/RFC5061", + } + +@misc{rfc5062, + author="R. Stewart and M. Tuexen and G. Camarillo", + title="{Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures}", + howpublished="RFC 5062 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5062", + pages="1--14", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5062.txt", + key="RFC 5062", + abstract={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.}, + doi="10.17487/RFC5062", + } + +@misc{rfc5063, + author="A. {Satyanarayana (Ed.)} and R. {Rahman (Ed.)}", + title="{Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart}", + howpublished="RFC 5063 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5063", + pages="1--24", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5063.txt", + key="RFC 5063", + abstract={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. 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. 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. These extensions are not used to create or restore data plane state. 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]}, + keywords="nodal faults, rsvp hello, state recovery", + doi="10.17487/RFC5063", + } + +@misc{rfc5064, + author="M. Duerst", + title="{The Archived-At Message Header Field}", + howpublished="RFC 5064 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5064", + pages="1--10", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5064.txt", + key="RFC 5064", + abstract={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]}, + keywords="", + doi="10.17487/RFC5064", + } + +@misc{rfc5065, + author="P. Traina and D. McPherson and J. Scudder", + title="{Autonomous System Confederations for BGP}", + howpublished="RFC 5065 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5065", + pages="1--14", + year=2007, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5065.txt", + key="RFC 5065", + abstract={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. 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. This document obsoletes RFC 3065. [STANDARDS-TRACK]}, + keywords="border gateway protocol, tcp/ip, full mesh", + doi="10.17487/RFC5065", + } + +@misc{rfc5066, + author="E. Beili", + title="{Ethernet in the First Mile Copper (EFMCu) Interfaces MIB}", + howpublished="RFC 5066 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5066", + pages="1--90", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7124", +url="https://www.rfc-editor.org/rfc/rfc5066.txt", + key="RFC 5066", + abstract={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]}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, MIB, Textual Conventions, 2BASE-TL, 10PASS-TS, 802.3ah, EFM, PAF, PME", + doi="10.17487/RFC5066", + } + +@misc{rfc5067, + author="S. Lind and P. Pfautz", + title="{Infrastructure ENUM Requirements}", + howpublished="RFC 5067 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5067", + pages="1--7", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5067.txt", + key="RFC 5067", + abstract={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.}, + keywords="e.164 number mapping, carrier", + doi="10.17487/RFC5067", + } + +@misc{rfc5068, + author="C. Hutzler and D. Crocker and P. Resnick and E. Allman and T. Finch", + title="{Email Submission Operations: Access and Accountability Requirements}", + howpublished="RFC 5068 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5068", + pages="1--12", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8314", +url="https://www.rfc-editor.org/rfc/rfc5068.txt", + key="RFC 5068", + abstract={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. 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.}, + keywords="spam, email abuse, phishing, email, e-mail, service, mime, rfc2822, rfc 2822, rfc822, rfc 822, rfc2821, rfc 2821, rfc821, rfc 821, architecture, mta, mua, msa, mda, user, delivery, relay, header, gateway agent, sieve, dsn, mdn, tussle, mhs, mail handling service, message transfer agent, message user agent, mail submission agent, mail delivery agent", + doi="10.17487/RFC5068", + } + +@misc{rfc5069, + author="T. {Taylor (Ed.)} and H. Tschofenig and H. Schulzrinne and M. Shanmugam", + title="{Security Threats and Requirements for Emergency Call Marking and Mapping}", + howpublished="RFC 5069 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5069", + pages="1--12", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5069.txt", + key="RFC 5069", + abstract={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. 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.}, + keywords="ecrit, public safety answering points, pasp", + doi="10.17487/RFC5069", + } + +@misc{rfc5070, + author="R. Danyliw and J. Meijer and Y. Demchenko", + title="{The Incident Object Description Exchange Format}", + howpublished="RFC 5070 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5070", + pages="1--92", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7970, updated by RFC 6685", +url="https://www.rfc-editor.org/rfc/rfc5070.txt", + key="RFC 5070", + abstract={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]}, + keywords="incident data format, compuer security incident, computer security incident response team, csirt, cert, security data sharing, computer network defense service provider, cndsp", + doi="10.17487/RFC5070", + } + +@misc{rfc5071, + author="D. Hankins", + title="{Dynamic Host Configuration Protocol Options Used by PXELINUX}", + howpublished="RFC 5071 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5071", + pages="1--14", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5071.txt", + key="RFC 5071", + abstract={This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211. This memo provides information for the Internet community.}, + keywords="dhcp, dhcp option codes", + doi="10.17487/RFC5071", + } + +@misc{rfc5072, + author="S. {Varada (Ed.)} and D. Haskins and E. Allen", + title="{IP Version 6 over PPP}", + howpublished="RFC 5072 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5072", + pages="1--16", + year=2007, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc5072.txt", + key="RFC 5072", + abstract={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. 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. 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. This document obsoletes RFC 2472. [STANDARDS-TRACK]}, + keywords="IPv6-PPP, internet, protocol, point-to-point, ipv6", + doi="10.17487/RFC5072", + } + +@misc{rfc5073, + author="J.P. {Vasseur (Ed.)} and J.L. Le {Roux (Ed.)}", + title="{IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities}", + howpublished="RFC 5073 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5073", + pages="1--13", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5073.txt", + key="RFC 5073", + abstract={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]}, + keywords="interior gateway protocol", + doi="10.17487/RFC5073", + } + +@misc{rfc5074, + author="S. Weiler", + title="{DNSSEC Lookaside Validation (DLV)}", + howpublished="RFC 5074 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5074", + pages="1--11", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5074.txt", + key="RFC 5074", + abstract={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.}, + keywords="dns security, trust anchors", + doi="10.17487/RFC5074", + } + +@misc{rfc5075, + author="B. {Haberman (Ed.)} and R. Hinden", + title="{IPv6 Router Advertisement Flags Option}", + howpublished="RFC 5075 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5075", + pages="1--7", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5175", +url="https://www.rfc-editor.org/rfc/rfc5075.txt", + key="RFC 5075", + abstract={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]}, + keywords="neighbor discovery protocol, ndp, expanded flags option, efo, ndp router advertisement message", + doi="10.17487/RFC5075", + } + +@misc{rfc5076, + author="B. Hoeneisen", + title="{ENUM Validation Information Mapping for the Extensible Provisioning Protocol}", + howpublished="RFC 5076 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5076", + pages="1--24", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5076.txt", + key="RFC 5076", + abstract={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]}, + keywords="epp, validation process, e.164, enum, enum domain name", + doi="10.17487/RFC5076", + } + +@misc{rfc5077, + author="J. Salowey and H. Zhou and P. Eronen and H. Tschofenig", + title="{Transport Layer Security (TLS) Session Resumption without Server-Side State}", + howpublished="RFC 5077 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5077", + pages="1--20", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8446, updated by RFC 8447", +url="https://www.rfc-editor.org/rfc/rfc5077.txt", + key="RFC 5077", + abstract={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]}, + keywords="", + doi="10.17487/RFC5077", + } + +@misc{rfc5078, + author="S. Dawkins", + title="{IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline}", + howpublished="RFC 5078 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5078", + pages="1--9", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7437", +url="https://www.rfc-editor.org/rfc/rfc5078.txt", + key="RFC 5078", + abstract={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.}, + keywords="Internet Architecture Board, Engineering Steering Group, nomcom", + doi="10.17487/RFC5078", + } + +@misc{rfc5079, + author="J. Rosenberg", + title="{Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5079 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5079", + pages="1--8", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5079.txt", + key="RFC 5079", + abstract={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]}, + keywords="anonymous calls", + doi="10.17487/RFC5079", + } + +@misc{rfc5080, + author="D. Nelson and A. DeKok", + title="{Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes}", + howpublished="RFC 5080 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5080", + pages="1--28", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5080.txt", + key="RFC 5080", + abstract={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]}, + keywords="", + doi="10.17487/RFC5080", + } + +@misc{rfc5081, + author="N. Mavrogiannopoulos", + title="{Using OpenPGP Keys for Transport Layer Security (TLS) Authentication}", + howpublished="RFC 5081 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5081", + pages="1--8", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6091", +url="https://www.rfc-editor.org/rfc/rfc5081.txt", + key="RFC 5081", + abstract={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.}, + keywords="tls handshake protocol, handshake", + doi="10.17487/RFC5081", + } + +@misc{rfc5082, + author="V. Gill and J. Heasley and D. Meyer and P. {Savola (Ed.)} and C. Pignataro", + title="{The Generalized TTL Security Mechanism (GTSM)}", + howpublished="RFC 5082 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5082", + pages="1--16", + year=2007, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5082.txt", + key="RFC 5082", + abstract={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]}, + keywords="time to live, packet hop limit", + doi="10.17487/RFC5082", + } + +@misc{rfc5083, + author="R. Housley", + title="{Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type}", + howpublished="RFC 5083 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5083", + pages="1--10", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5083.txt", + key="RFC 5083", + abstract={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]}, + keywords="encryption mode", + doi="10.17487/RFC5083", + } + +@misc{rfc5084, + author="R. Housley", + title="{Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 5084 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5084", + pages="1--11", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5084.txt", + key="RFC 5084", + abstract={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]}, + keywords="authenticated encryption algorithm", + doi="10.17487/RFC5084", + } + +@misc{rfc5085, + author="T. {Nadeau (Ed.)} and C. {Pignataro (Ed.)}", + title="{Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires}", + howpublished="RFC 5085 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5085", + pages="1--30", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5586", +url="https://www.rfc-editor.org/rfc/rfc5085.txt", + key="RFC 5085", + abstract={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]}, + keywords="pw", + doi="10.17487/RFC5085", + } + +@misc{rfc5086, + author="A. {Vainshtein (Ed.)} and I. Sasson and E. Metz and T. Frost and P. Pate", + title="{Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)}", + howpublished="RFC 5086 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5086", + pages="1--38", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5086.txt", + key="RFC 5086", + abstract={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.}, + keywords="nxds0, psn", + doi="10.17487/RFC5086", + } + +@misc{rfc5087, + author="Y(J). Stein and R. Shashoua and R. Insler and M. Anavi", + title="{Time Division Multiplexing over IP (TDMoIP)}", + howpublished="RFC 5087 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5087", + pages="1--50", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5087.txt", + key="RFC 5087", + abstract={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.}, + keywords="TDM, pseudowire, PWE3, TDMoIP, structure-aware TDM emulation", + doi="10.17487/RFC5087", + } + +@misc{rfc5088, + author="JL. Le {Roux (Ed.)} and JP. {Vasseur (Ed.)} and Y. Ikejiri and R. Zhang", + title="{OSPF Protocol Extensions for Path Computation Element (PCE) Discovery}", + howpublished="RFC 5088 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5088", + pages="1--20", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5088.txt", + key="RFC 5088", + abstract={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]}, + keywords="pcc, path computation client, open shortest path first", + doi="10.17487/RFC5088", + } + +@misc{rfc5089, + author="JL. Le {Roux (Ed.)} and JP. {Vasseur (Ed.)} and Y. Ikejiri and R. Zhang", + title="{IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery}", + howpublished="RFC 5089 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5089", + pages="1--17", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5089.txt", + key="RFC 5089", + abstract={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]}, + keywords="path computation client, pcc, intermediate system to intermediate system", + doi="10.17487/RFC5089", + } + +@misc{rfc5090, + author="B. Sterman and D. Sadolevsky and D. Schwartz and D. Williams and W. Beck", + title="{RADIUS Extension for Digest Authentication}", + howpublished="RFC 5090 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5090", + pages="1--33", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5090.txt", + key="RFC 5090", + abstract={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]}, + keywords="remote authentication dial-in user service, sip, http", + doi="10.17487/RFC5090", + } + +@misc{rfc5091, + author="X. Boyen and L. Martin", + title="{Identity-Based Cryptography Standard (IBCS) \#1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems}", + howpublished="RFC 5091 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5091", + pages="1--63", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5091.txt", + key="RFC 5091", + abstract={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.}, + keywords="Encryption, Cryptography, Security, Elliptic Curves, Elliptic Curve Cryptography, Pairing-based Cryptography, Identity-based Cryptography, Identity-based Encryption, Boneh-Franklin Encryption Scheme, Boneh-Boyen Encryption Scheme", + doi="10.17487/RFC5091", + } + +@misc{rfc5092, + author="A. {Melnikov (Ed.)} and C. Newman", + title="{IMAP URL Scheme}", + howpublished="RFC 5092 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5092", + pages="1--32", + year=2007, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5593", +url="https://www.rfc-editor.org/rfc/rfc5092.txt", + key="RFC 5092", + abstract={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. This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]}, + keywords="IMAP-URL, remote access store, Internet, Message, Access, Protocol, Uniform, Resource, Identifiers", + doi="10.17487/RFC5092", + } + +@misc{rfc5093, + author="G. Hunt", + title="{BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)}", + howpublished="RFC 5093 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5093", + pages="1--8", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5093.txt", + key="RFC 5093", + abstract={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.}, + keywords="next-generation network, rtcp xr, real time control protocol, extended reports, transport, metrics", + doi="10.17487/RFC5093", + } + +@misc{rfc5094, + author="V. Devarapalli and A. Patel and K. Leung", + title="{Mobile IPv6 Vendor Specific Option}", + howpublished="RFC 5094 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5094", + pages="1--7", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5094.txt", + key="RFC 5094", + abstract={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]}, + keywords="mobility header, mip6, mipv6", + doi="10.17487/RFC5094", + } + +@misc{rfc5095, + author="J. Abley and P. Savola and G. Neville-Neil", + title="{Deprecation of Type 0 Routing Headers in IPv6}", + howpublished="RFC 5095 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5095", + pages="1--7", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5095.txt", + key="RFC 5095", + abstract={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]}, + keywords="ipv6 type 0 routing header, traffic amplification", + doi="10.17487/RFC5095", + } + +@misc{rfc5096, + author="V. Devarapalli", + title="{Mobile IPv6 Experimental Messages}", + howpublished="RFC 5096 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5096", + pages="1--7", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5096.txt", + key="RFC 5096", + abstract={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]}, + keywords="mip6, mobility header, mobility option, mipv6", + doi="10.17487/RFC5096", + } + +@misc{rfc5097, + author="G. Renker and G. Fairhurst", + title="{MIB for the UDP-Lite protocol}", + howpublished="RFC 5097 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5097", + pages="1--23", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5097.txt", + key="RFC 5097", + abstract={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]}, + keywords="SMIv2, UDPLITE-MIB, management information base, lightweight user datagram protocol", + doi="10.17487/RFC5097", + } + +@misc{rfc5098, + author="G. Beacham and S. Kumar and S. Channabasappa", + title="{Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)}", + howpublished="RFC 5098 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5098", + pages="1--79", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5098.txt", + key="RFC 5098", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]}, + keywords="PKTC-IETF-SIG-MIB, snmp, simple network management protocol, packetcable-compliant, ipcablecom-compliant", + doi="10.17487/RFC5098", + } + +@misc{rfc5101, + author="B. {Claise (Ed.)}", + title="{Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information}", + howpublished="RFC 5101 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5101", + pages="1--63", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7011", +url="https://www.rfc-editor.org/rfc/rfc5101.txt", + key="RFC 5101", + abstract={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]}, + keywords="exporting process, collecting process, template records", + doi="10.17487/RFC5101", + } + +@misc{rfc5102, + author="J. Quittek and S. Bryant and B. Claise and P. Aitken and J. Meyer", + title="{Information Model for IP Flow Information Export}", + howpublished="RFC 5102 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5102", + pages="1--171", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7012, updated by RFC 6313", +url="https://www.rfc-editor.org/rfc/rfc5102.txt", + key="RFC 5102", + abstract={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]}, + keywords="ipfix, ip flow information export protocol, measured traffic, observation point, metering process, exporting process", + doi="10.17487/RFC5102", + } + +@misc{rfc5103, + author="B. Trammell and E. Boschi", + title="{Bidirectional Flow Export Using IP Flow Information Export (IPFIX)}", + howpublished="RFC 5103 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5103", + pages="1--24", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5103.txt", + key="RFC 5103", + abstract={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]}, + keywords="flow record, biflow", + doi="10.17487/RFC5103", + } + +@misc{rfc5104, + author="S. Wenger and U. Chandra and M. Westerlund and B. Burman", + title="{Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)}", + howpublished="RFC 5104 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5104", + pages="1--64", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7728, 8082", +url="https://www.rfc-editor.org/rfc/rfc5104.txt", + key="RFC 5104", + abstract={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. 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]}, + keywords="real time protocol, real-time protocol, , itu-t rec. h271, video back channel, full intra request, temporary maximum media stream bit rate, temporal-spatial trade-off", + doi="10.17487/RFC5104", + } + +@misc{rfc5105, + author="O. Lendl", + title="{ENUM Validation Token Format Definition}", + howpublished="RFC 5105 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5105", + pages="1--17", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5105.txt", + key="RFC 5105", + abstract={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]}, + keywords="telephone number mapping, e.164", + doi="10.17487/RFC5105", + } + +@misc{rfc5106, + author="H. Tschofenig and D. Kroeselberg and A. Pashalidis and Y. Ohba and F. Bersani", + title="{The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method}", + howpublished="RFC 5106 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5106", + pages="1--33", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5106.txt", + key="RFC 5106", + abstract={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.}, + keywords="cryptographic ciphersuite negotiation, hash function agility, identity confidentiality, fragmentation, fast reconnect mode", + doi="10.17487/RFC5106", + } + +@misc{rfc5107, + author="R. Johnson and J. Kumarasamy and K. Kinnear and M. Stapp", + title="{DHCP Server Identifier Override Suboption}", + howpublished="RFC 5107 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5107", + pages="1--7", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5107.txt", + key="RFC 5107", + abstract={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]}, + keywords="xml, extensible markup langauge, dynamic host configuration protocol, RENEW DHCPREQUEST, DHCP RENEW", + doi="10.17487/RFC5107", + } + +@misc{rfc5109, + author="A. {Li (Ed.)}", + title="{RTP Payload Format for Generic Forward Error Correction}", + howpublished="RFC 5109 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5109", + pages="1--44", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5109.txt", + key="RFC 5109", + abstract={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]}, + keywords="fec, realtime transport protocol", + doi="10.17487/RFC5109", + } + +@misc{rfc5110, + author="P. Savola", + title="{Overview of the Internet Multicast Routing Architecture}", + howpublished="RFC 5110 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5110", + pages="1--25", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5110.txt", + key="RFC 5110", + abstract={This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications. 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.}, + keywords="RFC 3913, RFC 2189, RFC 2201, RFC 1584", + doi="10.17487/RFC5110", + } + +@misc{rfc5111, + author="B. Aboba and L. Dondeti", + title="{Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF)}", + howpublished="RFC 5111 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5111", + pages="1--8", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5111.txt", + key="RFC 5111", + abstract={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.}, + keywords="working group formation, bof, birds of a feather", + doi="10.17487/RFC5111", + } + +@misc{rfc5112, + author="M. Garcia-Martin", + title="{The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)}", + howpublished="RFC 5112 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5112", + pages="1--25", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5112.txt", + key="RFC 5112", + abstract={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]}, + keywords="communication session, event notification, presence", + doi="10.17487/RFC5112", + } + +@misc{rfc5113, + author="J. Arkko and B. Aboba and J. {Korhonen (Ed.)} and F. Bari", + title="{Network Discovery and Selection Problem}", + howpublished="RFC 5113 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5113", + pages="1--39", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5113.txt", + key="RFC 5113", + abstract={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.}, + doi="10.17487/RFC5113", + } + +@misc{rfc5114, + author="M. Lepinski and S. Kent", + title="{Additional Diffie-Hellman Groups for Use with IETF Standards}", + howpublished="RFC 5114 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5114", + pages="1--23", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5114.txt", + key="RFC 5114", + abstract={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). 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. 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.}, + keywords="elliptic curve, ike, tls, ssh, smime, x.509", + doi="10.17487/RFC5114", + } + +@misc{rfc5115, + author="K. Carlberg and P. O'Hanlon", + title="{Telephony Routing over IP (TRIP) Attribute for Resource Priority}", + howpublished="RFC 5115 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5115", + pages="1--8", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5115.txt", + key="RFC 5115", + abstract={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]}, + keywords="ip telephony, ResourcePriority", + doi="10.17487/RFC5115", + } + +@misc{rfc5116, + author="D. McGrew", + title="{An Interface and Algorithms for Authenticated Encryption}", + howpublished="RFC 5116 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5116", + pages="1--22", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5116.txt", + key="RFC 5116", + abstract={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]}, + keywords="Encryption, Authentication, AEAD, authenticated encryption with associated data", + doi="10.17487/RFC5116", + } + +@misc{rfc5117, + author="M. Westerlund and S. Wenger", + title="{RTP Topologies}", + howpublished="RFC 5117 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5117", + pages="1--21", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7667", +url="https://www.rfc-editor.org/rfc/rfc5117.txt", + key="RFC 5117", + abstract={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.}, + keywords="multi-endpoint topologies, real-time transport protocol", + doi="10.17487/RFC5117", + } + +@misc{rfc5118, + author="V. Gurbani and C. Boulton and R. Sparks", + title="{Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)}", + howpublished="RFC 5118 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5118", + pages="1--18", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5118.txt", + key="RFC 5118", + abstract={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.}, + keywords="Torture test, IPv6, SIP", + doi="10.17487/RFC5118", + } + +@misc{rfc5119, + author="T. Edwards", + title="{A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE)}", + howpublished="RFC 5119 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5119", + pages="1--9", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5119.txt", + key="RFC 5119", + abstract={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.}, + keywords="persistent resources, universal labels,", + doi="10.17487/RFC5119", + } + +@misc{rfc5120, + author="T. Przygienda and N. Shen and N. Sheth", + title="{M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)}", + howpublished="RFC 5120 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5120", + pages="1--14", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5120.txt", + key="RFC 5120", + abstract={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]}, + keywords="is-is", + doi="10.17487/RFC5120", + } + +@misc{rfc5121, + author="B. Patil and F. Xia and B. Sarikaya and JH. Choi and S. Madanapalli", + title="{Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks}", + howpublished="RFC 5121 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5121", + pages="1--22", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8064", +url="https://www.rfc-editor.org/rfc/rfc5121.txt", + key="RFC 5121", + abstract={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]}, + keywords="Neighbor Discovery, Per-MS Perfix", + doi="10.17487/RFC5121", + } + +@misc{rfc5122, + author="P. Saint-Andre", + title="{Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 5122 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5122", + pages="1--26", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5122.txt", + key="RFC 5122", + abstract={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]}, + keywords="Extensible Messaging and Presence Protocol, Internationalized Resource Identifier, Uniform Resource Identifier, Jabber, xmpp, iri, uri", + doi="10.17487/RFC5122", + } + +@misc{rfc5123, + author="R. White and B. Akyol", + title="{Considerations in Validating the Path in BGP}", + howpublished="RFC 5123 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5123", + pages="1--16", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5123.txt", + key="RFC 5123", + abstract={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.}, + keywords="bgp autonomous system path, bgp as path", + doi="10.17487/RFC5123", + } + +@misc{rfc5124, + author="J. Ott and E. Carrara", + title="{Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)}", + howpublished="RFC 5124 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5124", + pages="1--18", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5124.txt", + key="RFC 5124", + abstract={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]}, + keywords="avpf, rtp communication", + doi="10.17487/RFC5124", + } + +@misc{rfc5125, + author="T. Taylor", + title="{Reclassification of RFC 3525 to Historic}", + howpublished="RFC 5125 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5125", + pages="1--4", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5125.txt", + key="RFC 5125", + abstract={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.}, + keywords="MEGACO, H.248, media, gateway, control", + doi="10.17487/RFC5125", + } + +@misc{rfc5126, + author="D. Pinkas and N. Pope and J. Ross", + title="{CMS Advanced Electronic Signatures (CAdES)}", + howpublished="RFC 5126 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5126", + pages="1--141", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5126.txt", + key="RFC 5126", + abstract={This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature. 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. 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. 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.}, + keywords="verifying party, signer, purchase, contract, invoice, application, smart cards, data", + doi="10.17487/RFC5126", + } + +@misc{rfc5127, + author="K. Chan and J. Babiarz and F. Baker", + title="{Aggregation of Diffserv Service Classes}", + howpublished="RFC 5127 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5127", + pages="1--19", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5127.txt", + key="RFC 5127", + abstract={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.}, + keywords="Treatment Aggregate, forwarding treatment", + doi="10.17487/RFC5127", + } + +@misc{rfc5128, + author="P. Srisuresh and B. Ford and D. Kegel", + title="{State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)}", + howpublished="RFC 5128 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5128", + pages="1--32", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5128.txt", + key="RFC 5128", + abstract={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.}, + doi="10.17487/RFC5128", + } + +@misc{rfc5129, + author="B. Davie and B. Briscoe and J. Tay", + title="{Explicit Congestion Marking in MPLS}", + howpublished="RFC 5129 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5129", + pages="1--21", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5462", +url="https://www.rfc-editor.org/rfc/rfc5129.txt", + key="RFC 5129", + abstract={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]}, + keywords="Diffserv, Differentiated Services, QOS, ECN tunnel", + doi="10.17487/RFC5129", + } + +@misc{rfc5130, + author="S. Previdi and M. {Shand (Ed.)} and C. Martin", + title="{A Policy Control Mechanism in IS-IS Using Administrative Tags}", + howpublished="RFC 5130 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5130", + pages="1--8", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5130.txt", + key="RFC 5130", + abstract={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]}, + keywords="intermediate systetm to intermediate system, ip prefix distribution, lsp, link state protocol", + doi="10.17487/RFC5130", + } + +@misc{rfc5131, + author="D. {McWalter (Ed.)}", + title="{A MIB Textual Convention for Language Tags}", + howpublished="RFC 5131 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5131", + pages="1--6", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5131.txt", + key="RFC 5131", + abstract={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]}, + keywords="LANGTAG-TC-MIB", + doi="10.17487/RFC5131", + } + +@misc{rfc5132, + author="D. McWalter and D. Thaler and A. Kessler", + title="{IP Multicast MIB}", + howpublished="RFC 5132 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5132", + pages="1--59", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5132.txt", + key="RFC 5132", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. [STANDARDS-TRACK]}, + keywords="managament information base, IPMCAST-MIB,", + doi="10.17487/RFC5132", + } + +@misc{rfc5133, + author="M. Tuexen and K. Morneault", + title="{Terminal Endpoint Identifier (TEI) Query Request Number Change}", + howpublished="RFC 5133 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5133", + pages="1--4", + year=2007, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5133.txt", + key="RFC 5133", + abstract={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]}, + keywords="isdn q.921-user adaptation layer, iua", + doi="10.17487/RFC5133", + } + +@misc{rfc5134, + author="M. Mealling", + title="{A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards}", + howpublished="RFC 5134 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5134", + pages="1--10", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5134.txt", + key="RFC 5134", + abstract={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.}, + keywords="uniform resource name, Auto-ID, RFID, EPCglobal, EPC, UPC, supply chain management, bar code", + doi="10.17487/RFC5134", + } + +@misc{rfc5135, + author="D. Wing and T. Eckert", + title="{IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)}", + howpublished="RFC 5135 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5135", + pages="1--16", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5135.txt", + key="RFC 5135", + abstract={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.}, + keywords="multicast application, multicast nat", + doi="10.17487/RFC5135", + } + +@misc{rfc5136, + author="P. Chimento and J. Ishac", + title="{Defining Network Capacity}", + howpublished="RFC 5136 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5136", + pages="1--14", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5136.txt", + key="RFC 5136", + abstract={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.}, + keywords="bandwidth, bandwidth estimation, capacity estimation, link capacity, available capacity, narrow link, tight link", + doi="10.17487/RFC5136", + } + +@misc{rfc5137, + author="J. Klensin", + title="{ASCII Escaping of Unicode Characters}", + howpublished="RFC 5137 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5137", + pages="1--13", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5137.txt", + key="RFC 5137", + abstract={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.}, + keywords="Text, internationalization, ascii, unicode, utf-8, encoding", + doi="10.17487/RFC5137", + } + +@misc{rfc5138, + author="S. Cox", + title="{A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI)}", + howpublished="RFC 5138 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5138", + pages="1--8", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5138.txt", + key="RFC 5138", + abstract={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.}, + doi="10.17487/RFC5138", + } + +@misc{rfc5139, + author="M. Thomson and J. Winterbottom", + title="{Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)}", + howpublished="RFC 5139 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5139", + pages="1--14", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5139.txt", + key="RFC 5139", + abstract={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]}, + keywords="location, civic location, pidf-lo, civic address", + doi="10.17487/RFC5139", + } + +@misc{rfc5140, + author="M. Bangalore and R. Kumar and J. Rosenberg and H. Salama and D.N. Shah", + title="{A Telephony Gateway REgistration Protocol (TGREP)}", + howpublished="RFC 5140 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5140", + pages="1--28", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5140.txt", + key="RFC 5140", + abstract={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]}, + keywords="telephony prefix, soft switches, telephony routing over ip, trip, internet telephony administrative domains, itad", + doi="10.17487/RFC5140", + } + +@misc{rfc5141, + author="J. Goodwin and H. Apel", + title="{A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)}", + howpublished="RFC 5141 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5141", + pages="1--28", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5141.txt", + key="RFC 5141", + abstract={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.}, + keywords="urn nid, uniform resource name namespace identification, NSS", + doi="10.17487/RFC5141", + } + +@misc{rfc5142, + author="B. Haley and V. Devarapalli and H. Deng and J. Kempf", + title="{Mobility Header Home Agent Switch Message}", + howpublished="RFC 5142 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5142", + pages="1--13", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5142.txt", + key="RFC 5142", + abstract={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]}, + keywords="", + doi="10.17487/RFC5142", + } + +@misc{rfc5143, + author="A. Malis and J. Brayley and J. Shirron and L. Martini and S. Vogelsang", + title="{Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation}", + howpublished="RFC 5143 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5143", + pages="1--24", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 4842", +url="https://www.rfc-editor.org/rfc/rfc5143.txt", + key="RFC 5143", + abstract={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.}, + keywords="psn, packet switched network, RFC4842", + doi="10.17487/RFC5143", + } + +@misc{rfc5144, + author="A. Newton and M. Sanz", + title="{A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)}", + howpublished="RFC 5144 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5144", + pages="1--17", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5144.txt", + key="RFC 5144", + abstract={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]}, + keywords="dreg, iris domain registry", + doi="10.17487/RFC5144", + } + +@misc{rfc5145, + author="K. {Shiomoto (Ed.)}", + title="{Framework for MPLS-TE to GMPLS Migration}", + howpublished="RFC 5145 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5145", + pages="1--19", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5145.txt", + key="RFC 5145", + abstract={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. 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. This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. This memo provides informati on for the Internet community.}, + keywords="multiprotocol label switching traffic engineering, control plane", + doi="10.17487/RFC5145", + } + +@misc{rfc5146, + author="K. {Kumaki (Ed.)}", + title="{Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks}", + howpublished="RFC 5146 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5146", + pages="1--15", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5146.txt", + key="RFC 5146", + abstract={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). 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. 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.}, + keywords="multiprotocol label switching traffic engineering, service provider requirements", + doi="10.17487/RFC5146", + } + +@misc{rfc5147, + author="E. Wilde and M. Duerst", + title="{URI Fragment Identifiers for the text/plain Media Type}", + howpublished="RFC 5147 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5147", + pages="1--17", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5147.txt", + key="RFC 5147", + abstract={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]}, + keywords="uniform resource identifier, mime entity", + doi="10.17487/RFC5147", + } + +@misc{rfc5148, + author="T. Clausen and C. Dearlove and B. Adamson", + title="{Jitter Considerations in Mobile Ad Hoc Networks (MANETs)}", + howpublished="RFC 5148 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5148", + pages="1--12", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5148.txt", + key="RFC 5148", + abstract={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.}, + keywords="randomly modifying timing, control traffic transmission, tranmission collision", + doi="10.17487/RFC5148", + } + +@misc{rfc5149, + author="J. Korhonen and U. Nilsson and V. Devarapalli", + title="{Service Selection for Mobile IPv6}", + howpublished="RFC 5149 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5149", + pages="1--9", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5149.txt", + key="RFC 5149", + abstract={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.}, + keywords="mipv6, service selection mobility option, proxy mobile ipv6, mobilty service subscription, binding registration procedure", + doi="10.17487/RFC5149", + } + +@misc{rfc5150, + author="A. Ayyangar and K. Kompella and JP. Vasseur and A. Farrel", + title="{Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)}", + howpublished="RFC 5150 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5150", + pages="1--19", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5150.txt", + key="RFC 5150", + abstract={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). 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. 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]}, + keywords="lsp, label switched paths, e2e lsp, lsp stitching, lsp segments, s-lsp", + doi="10.17487/RFC5150", + } + +@misc{rfc5151, + author="A. {Farrel (Ed.)} and A. Ayyangar and JP. Vasseur", + title="{Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions}", + howpublished="RFC 5151 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5151", + pages="1--25", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5151.txt", + key="RFC 5151", + abstract={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. 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]}, + keywords="multiprotocol label switching, mpls-te", + doi="10.17487/RFC5151", + } + +@misc{rfc5152, + author="JP. {Vasseur (Ed.)} and A. {Ayyangar (Ed.)} and R. Zhang", + title="{A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)}", + howpublished="RFC 5152 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5152", + pages="1--21", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5152.txt", + key="RFC 5152", + abstract={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. 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. [STAND ARDS-TRACK]}, + keywords="mpls, gmpls", + doi="10.17487/RFC5152", + } + +@misc{rfc5153, + author="E. Boschi and L. Mark and J. Quittek and M. Stiemerling and P. Aitken", + title="{IP Flow Information Export (IPFIX) Implementation Guidelines}", + howpublished="RFC 5153 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5153", + pages="1--35", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5153.txt", + key="RFC 5153", + abstract={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.}, + keywords="template mangaement, exporting processes, collecting processes, ipfix middleboxes", + doi="10.17487/RFC5153", + } + +@misc{rfc5154, + author="J. {Jee (Ed.)} and S. Madanapalli and J. Mandin", + title="{IP over IEEE 802.16 Problem Statement and Goals}", + howpublished="RFC 5154 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5154", + pages="1--14", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5154.txt", + key="RFC 5154", + abstract={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.}, + keywords="WiMAX, Mobile WiMAX, WiBro", + doi="10.17487/RFC5154", + } + +@misc{rfc5155, + author="B. Laurie and G. Sisson and R. Arends and D. Blacka", + title="{DNS Security (DNSSEC) Hashed Authenticated Denial of Existence}", + howpublished="RFC 5155 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5155", + pages="1--52", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6840, 6944", +url="https://www.rfc-editor.org/rfc/rfc5155.txt", + key="RFC 5155", + abstract={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]}, + keywords="domain name system, nsec, resource record, nsec3", + doi="10.17487/RFC5155", + } + +@misc{rfc5156, + author="M. Blanchet", + title="{Special-Use IPv6 Addresses}", + howpublished="RFC 5156 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5156", + pages="1--7", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6890", +url="https://www.rfc-editor.org/rfc/rfc5156.txt", + key="RFC 5156", + abstract={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.}, + keywords="invalid routing prefix", + doi="10.17487/RFC5156", + } + +@misc{rfc5157, + author="T. Chown", + title="{IPv6 Implications for Network Scanning}", + howpublished="RFC 5157 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5157", + pages="1--13", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7707", +url="https://www.rfc-editor.org/rfc/rfc5157.txt", + key="RFC 5157", + abstract={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.}, + keywords="subnet address space", + doi="10.17487/RFC5157", + } + +@misc{rfc5158, + author="G. Huston", + title="{6to4 Reverse DNS Delegation Specification}", + howpublished="RFC 5158 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5158", + pages="1--12", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5158.txt", + key="RFC 5158", + abstract={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.}, + keywords="dns, domain name system", + doi="10.17487/RFC5158", + } + +@misc{rfc5159, + author="L. {Dondeti (Ed.)} and A. Jerichow", + title="{Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection}", + howpublished="RFC 5159 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5159", + pages="1--8", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5159.txt", + key="RFC 5159", + abstract={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.}, + keywords="SDP, IANA registration, OMA BCAST", + doi="10.17487/RFC5159", + } + +@misc{rfc5160, + author="P. Levis and M. Boucadair", + title="{Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)}", + howpublished="RFC 5160 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5160", + pages="1--19", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5160.txt", + key="RFC 5160", + abstract={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.}, + keywords="sls, bgp, peering, diffserv, parallel internet", + doi="10.17487/RFC5160", + } + +@misc{rfc5161, + author="A. {Gulbrandsen (Ed.)} and A. {Melnikov (Ed.)}", + title="{The IMAP ENABLE Extension}", + howpublished="RFC 5161 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5161", + pages="1--7", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5161.txt", + key="RFC 5161", + abstract={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]}, + keywords="Internet Message Access Protocol", + doi="10.17487/RFC5161", + } + +@misc{rfc5162, + author="A. Melnikov and D. Cridland and C. Wilson", + title="{IMAP4 Extensions for Quick Mailbox Resynchronization}", + howpublished="RFC 5162 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5162", + pages="1--23", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7162", +url="https://www.rfc-editor.org/rfc/rfc5162.txt", + key="RFC 5162", + abstract={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]}, + keywords="Internet Message Access Protocol", + doi="10.17487/RFC5162", + } + +@misc{rfc5163, + author="G. Fairhurst and B. Collini-Nocker", + title="{Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)}", + howpublished="RFC 5163 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5163", + pages="1--18", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5163.txt", + key="RFC 5163", + abstract={This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326. 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]}, + keywords="digital video broadcasting, dvb, mpeg-2 ts-concat, pdu-concat, timestamp", + doi="10.17487/RFC5163", + } + +@misc{rfc5164, + author="T. {Melia (Ed.)}", + title="{Mobility Services Transport: Problem Statement}", + howpublished="RFC 5164 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5164", + pages="1--16", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5164.txt", + key="RFC 5164", + abstract={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.}, + keywords="intelligent access selection, ip handover mechanism", + doi="10.17487/RFC5164", + } + +@misc{rfc5165, + author="C. Reed", + title="{A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC)}", + howpublished="RFC 5165 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5165", + pages="1--7", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5165.txt", + key="RFC 5165", + abstract={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.}, + keywords="location, geospatial, namespace, OGC, URN, Open Geospatial Consortium", + doi="10.17487/RFC5165", + } + +@misc{rfc5166, + author="S. {Floyd (Ed.)}", + title="{Metrics for the Evaluation of Congestion Control Mechanisms}", + howpublished="RFC 5166 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5166", + pages="1--23", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5166.txt", + key="RFC 5166", + abstract={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. 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 b etween 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.}, + keywords="transport protocol, transport modeling research group, tmrg", + doi="10.17487/RFC5166", + } + +@misc{rfc5167, + author="M. Dolly and R. Even", + title="{Media Server Control Protocol Requirements}", + howpublished="RFC 5167 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5167", + pages="1--9", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5167.txt", + key="RFC 5167", + abstract={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. 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.}, + keywords="logical entities, mcp, interactive voice response, conferencing media services", + doi="10.17487/RFC5167", + } + +@misc{rfc5168, + author="O. Levin and R. Even and P. Hagendorf", + title="{XML Schema for Media Control}", + howpublished="RFC 5168 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5168", + pages="1--10", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5168.txt", + key="RFC 5168", + abstract={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.}, + keywords="extensible markup language, video fast update", + doi="10.17487/RFC5168", + } + +@misc{rfc5169, + author="T. Clancy and M. Nakhjiri and V. Narayanan and L. Dondeti", + title="{Handover Key Management and Re-Authentication Problem Statement}", + howpublished="RFC 5169 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5169", + pages="1--15", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5169.txt", + key="RFC 5169", + abstract={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.}, + keywords="hokey, handover key management, fast re-authentication, mobility", + doi="10.17487/RFC5169", + } + +@misc{rfc5170, + author="V. Roca and C. Neumann and D. Furodet", + title="{Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes}", + howpublished="RFC 5170 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5170", + pages="1--33", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5170.txt", + key="RFC 5170", + abstract={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]}, + keywords="LDPC, FEC", + doi="10.17487/RFC5170", + } + +@misc{rfc5171, + author="M. Foschiano", + title="{Cisco Systems UniDirectional Link Detection (UDLD) Protocol}", + howpublished="RFC 5171 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5171", + pages="1--13", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5171.txt", + key="RFC 5171", + abstract={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. 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.}, + keywords="Ethernet, switches, LAN, IEEE, 802, spanning tree, STP, FEFI, autonegotiation", + doi="10.17487/RFC5171", + } + +@misc{rfc5172, + author="S. {Varada (Ed.)}", + title="{Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol}", + howpublished="RFC 5172 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5172", + pages="1--7", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5172.txt", + key="RFC 5172", + abstract={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. 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. This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]}, + keywords="IPv6-PPP, internet, protocol, point-to-point, ipv6", + doi="10.17487/RFC5172", + } + +@misc{rfc5173, + author="J. Degener and P. Guenther", + title="{Sieve Email Filtering: Body Extension}", + howpublished="RFC 5173 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5173", + pages="1--10", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5173.txt", + key="RFC 5173", + abstract={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]}, + keywords="search, full text, email", + doi="10.17487/RFC5173", + } + +@misc{rfc5174, + author="J-P. Evain", + title="{A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU)}", + howpublished="RFC 5174 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5174", + pages="1--8", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5174.txt", + key="RFC 5174", + abstract={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.}, + keywords="EBU, namespace, urn, broadcast, metadata, classification, schema", + doi="10.17487/RFC5174", + } + +@misc{rfc5175, + author="B. {Haberman (Ed.)} and R. Hinden", + title="{IPv6 Router Advertisement Flags Option}", + howpublished="RFC 5175 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5175", + pages="1--7", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5175.txt", + key="RFC 5175", + abstract={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]}, + keywords="neighbor discovery protocol, ndp, expanded flags option, efo, ndp router advertisement message", + doi="10.17487/RFC5175", + } + +@misc{rfc5176, + author="M. Chiba and G. Dommety and M. Eklund and D. Mitton and B. Aboba", + title="{Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)}", + howpublished="RFC 5176 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5176", + pages="1--34", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5176.txt", + key="RFC 5176", + abstract={This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.}, + keywords="user session", + doi="10.17487/RFC5176", + } + +@misc{rfc5177, + author="K. Leung and G. Dommety and V. Narayanan and A. Petrescu", + title="{Network Mobility (NEMO) Extensions for Mobile IPv4}", + howpublished="RFC 5177 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5177", + pages="1--26", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6626", +url="https://www.rfc-editor.org/rfc/rfc5177.txt", + key="RFC 5177", + abstract={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. Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]}, + keywords="NEMOv4, Mobile Networks, Moving Networks, Mobile Router, Local Fixed Node, Prefix Table, Mobile Network Prefix, Nested Mobile Networks, Nested Network Mobility", + doi="10.17487/RFC5177", + } + +@misc{rfc5178, + author="N. Williams and A. Melnikov", + title="{Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type}", + howpublished="RFC 5178 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5178", + pages="1--9", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5178.txt", + key="RFC 5178", + abstract={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. 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]}, + keywords="domain-based-name, gss-domain-based-services, GSS\_C\_NT\_DOMAINBASED\_SERVICE", + doi="10.17487/RFC5178", + } + +@misc{rfc5179, + author="N. Williams", + title="{Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism}", + howpublished="RFC 5179 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5179", + pages="1--5", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5179.txt", + key="RFC 5179", + abstract={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]}, + keywords="domain-name-based, GSS\_C\_NT\_DOMAINBASED\_SERVICE", + doi="10.17487/RFC5179", + } + +@misc{rfc5180, + author="C. Popoviciu and A. Hamza and G. Van de Velde and D. Dugatkin", + title="{IPv6 Benchmarking Methodology for Network Interconnect Devices}", + howpublished="RFC 5180 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5180", + pages="1--20", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5180.txt", + key="RFC 5180", + abstract={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.}, + keywords="rfc2544, ipv6, benchmarking guidelines", + doi="10.17487/RFC5180", + } + +@misc{rfc5181, + author="M-K. {Shin (Ed.)} and Y-H. Han and S-E. Kim and D. Premec", + title="{IPv6 Deployment Scenarios in 802.16 Networks}", + howpublished="RFC 5181 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5181", + pages="1--16", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5181.txt", + key="RFC 5181", + abstract={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.}, + keywords="Ethernet CS (Convergence Sublayer), IPv6 CS (Convergence Sublayer)", + doi="10.17487/RFC5181", + } + +@misc{rfc5182, + author="A. Melnikov", + title="{IMAP Extension for Referencing the Last SEARCH Result}", + howpublished="RFC 5182 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5182", + pages="1--13", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5182.txt", + key="RFC 5182", + abstract={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. 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. 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]}, + keywords="uid, unique identifier, searchres, internet message access protocol", + doi="10.17487/RFC5182", + } + +@misc{rfc5183, + author="N. Freed", + title="{Sieve Email Filtering: Environment Extension}", + howpublished="RFC 5183 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5183", + pages="1--10", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5183.txt", + key="RFC 5183", + abstract={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]}, + keywords="vnd", + doi="10.17487/RFC5183", + } + +@misc{rfc5184, + author="F. Teraoka and K. Gogo and K. Mitsuya and R. Shibui and K. Mitani", + title="{Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover}", + howpublished="RFC 5184 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5184", + pages="1--29", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5184.txt", + key="RFC 5184", + abstract={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.}, + keywords="l2 triggers, primitives, l3-driven fast handover, ip mobility optimizations, mobopts", + doi="10.17487/RFC5184", + } + +@misc{rfc5185, + author="S. Mirtorabi and P. Psenak and A. {Lindem (Ed.)} and A. Oswal", + title="{OSPF Multi-Area Adjacency}", + howpublished="RFC 5185 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5185", + pages="1--11", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5185.txt", + key="RFC 5185", + abstract={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]}, + keywords="open shortest path first, inter-area, intra-area path", + doi="10.17487/RFC5185", + } + +@misc{rfc5186, + author="B. Haberman and J. Martin", + title="{Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction}", + howpublished="RFC 5186 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5186", + pages="1--6", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5186.txt", + key="RFC 5186", + abstract={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.}, + keywords="source information, source-filtering group management", + doi="10.17487/RFC5186", + } + +@misc{rfc5187, + author="P. Pillay-Esnault and A. Lindem", + title="{OSPFv3 Graceful Restart}", + howpublished="RFC 5187 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5187", + pages="1--7", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5187.txt", + key="RFC 5187", + abstract={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]}, + keywords="open shortest path first", + doi="10.17487/RFC5187", + } + +@misc{rfc5188, + author="H. Desineni and Q. Xie", + title="{RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec}", + howpublished="RFC 5188 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5188", + pages="1--25", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5188.txt", + key="RFC 5188", + abstract={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]}, + doi="10.17487/RFC5188", + } + +@misc{rfc5189, + author="M. Stiemerling and J. Quittek and T. Taylor", + title="{Middlebox Communication (MIDCOM) Protocol Semantics}", + howpublished="RFC 5189 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5189", + pages="1--70", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5189.txt", + key="RFC 5189", + abstract={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]}, + keywords="nat, network address translator, firewall", + doi="10.17487/RFC5189", + } + +@misc{rfc5190, + author="J. Quittek and M. Stiemerling and P. Srisuresh", + title="{Definitions of Managed Objects for Middlebox Communication}", + howpublished="RFC 5190 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5190", + pages="1--92", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5190.txt", + key="RFC 5190", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow 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]}, + keywords="management information base, mib, midcom, MIDCOM-MIB", + doi="10.17487/RFC5190", + } + +@misc{rfc5191, + author="D. Forsberg and Y. {Ohba (Ed.)} and B. Patil and H. Tschofenig and A. Yegin", + title="{Protocol for Carrying Authentication for Network Access (PANA)}", + howpublished="RFC 5191 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5191", + pages="1--46", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5872", +url="https://www.rfc-editor.org/rfc/rfc5191.txt", + key="RFC 5191", + abstract={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]}, + keywords="eap, exensible authentication protocol", + doi="10.17487/RFC5191", + } + +@misc{rfc5192, + author="L. Morand and A. Yegin and S. Kumar and S. Madanapalli", + title="{DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents}", + howpublished="RFC 5192 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5192", + pages="1--8", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5192.txt", + key="RFC 5192", + abstract={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]}, + keywords="dynamic host configuration protocol, pac, pana client", + doi="10.17487/RFC5192", + } + +@misc{rfc5193, + author="P. Jayaraman and R. Lopez and Y. {Ohba (Ed.)} and M. Parthasarathy and A. Yegin", + title="{Protocol for Carrying Authentication for Network Access (PANA) Framework}", + howpublished="RFC 5193 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5193", + pages="1--11", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5193.txt", + key="RFC 5193", + abstract={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.}, + keywords="", + doi="10.17487/RFC5193", + } + +@misc{rfc5194, + author="A. van {Wijk (Ed.)} and G. {Gybels (Ed.)}", + title="{Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)}", + howpublished="RFC 5194 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5194", + pages="1--31", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5194.txt", + key="RFC 5194", + abstract={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.}, + keywords="text telephone, textphone, deaf, hard-of-hearing, speech-impaired, interactive text, transcoding, speech-to-text, user alerting, emergency services, gateway, analog terminal adapters, PSTN interworking, text presentation, user alerting, instant messaging, conversation, conversational text, interactivity, total conversation, user requirements, text gateway, relay, relay service, text relay, TTY, text transport, text interworking, combination gateway", + doi="10.17487/RFC5194", + } + +@misc{rfc5195, + author="H. Ould-Brahim and D. Fedyk and Y. Rekhter", + title="{BGP-Based Auto-Discovery for Layer-1 VPNs}", + howpublished="RFC 5195 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5195", + pages="1--10", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5195.txt", + key="RFC 5195", + abstract={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]}, + keywords="import route target, l1vpn, single-end provisioning", + doi="10.17487/RFC5195", + } + +@misc{rfc5196, + author="M. Lonnfors and K. Kiss", + title="{Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)}", + howpublished="RFC 5196 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5196", + pages="1--30", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5196.txt", + key="RFC 5196", + abstract={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]}, + keywords="common presence data format, cpp, common profile for presence", + doi="10.17487/RFC5196", + } + +@misc{rfc5197, + author="S. Fries and D. Ignjatic", + title="{On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions}", + howpublished="RFC 5197 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5197", + pages="1--31", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5197.txt", + key="RFC 5197", + abstract={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. 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 d iscussed 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.}, + keywords="key management, media stream security, end-to-end, SRTP", + doi="10.17487/RFC5197", + } + +@misc{rfc5198, + author="J. Klensin and M. Padlipsky", + title="{Unicode Format for Network Interchange}", + howpublished="RFC 5198 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5198", + pages="1--19", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5198.txt", + key="RFC 5198", + abstract={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]}, + keywords="internationalized, utf-8", + doi="10.17487/RFC5198", + } + +@misc{rfc5201, + author="R. Moskowitz and P. Nikander and P. {Jokela (Ed.)} and T. Henderson", + title="{Host Identity Protocol}", + howpublished="RFC 5201 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5201", + pages="1--104", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7401, updated by RFC 6253", +url="https://www.rfc-editor.org/rfc/rfc5201.txt", + key="RFC 5201", + abstract={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.}, + keywords="hip, ip-layer state, integrity protection, optional encryption", + doi="10.17487/RFC5201", + } + +@misc{rfc5202, + author="P. Jokela and R. Moskowitz and P. Nikander", + title="{Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)}", + howpublished="RFC 5202 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5202", + pages="1--30", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7402", +url="https://www.rfc-editor.org/rfc/rfc5202.txt", + key="RFC 5202", + abstract={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.}, + keywords="user data packets", + doi="10.17487/RFC5202", + } + +@misc{rfc5203, + author="J. Laganier and T. Koponen and L. Eggert", + title="{Host Identity Protocol (HIP) Registration Extension}", + howpublished="RFC 5203 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5203", + pages="1--13", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8003", +url="https://www.rfc-editor.org/rfc/rfc5203.txt", + key="RFC 5203", + abstract={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.}, + keywords="register", + doi="10.17487/RFC5203", + } + +@misc{rfc5204, + author="J. Laganier and L. Eggert", + title="{Host Identity Protocol (HIP) Rendezvous Extension}", + howpublished="RFC 5204 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5204", + pages="1--15", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8004", +url="https://www.rfc-editor.org/rfc/rfc5204.txt", + key="RFC 5204", + abstract={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.}, + keywords="hip registration extension, hip nodes, hip redezvous server", + doi="10.17487/RFC5204", + } + +@misc{rfc5205, + author="P. Nikander and J. Laganier", + title="{Host Identity Protocol (HIP) Domain Name System (DNS) Extensions}", + howpublished="RFC 5205 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5205", + pages="1--17", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8005", +url="https://www.rfc-editor.org/rfc/rfc5205.txt", + key="RFC 5205", + abstract={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.}, + keywords="hip, host identity protocol, host identity payload, dns, domain name system", + doi="10.17487/RFC5205", + } + +@misc{rfc5206, + author="P. Nikander and T. {Henderson (Ed.)} and C. Vogt and J. Arkko", + title="{End-Host Mobility and Multihoming with the Host Identity Protocol}", + howpublished="RFC 5206 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5206", + pages="1--40", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8046", +url="https://www.rfc-editor.org/rfc/rfc5206.txt", + key="RFC 5206", + abstract={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.}, + keywords="hip, multihoming extensions, mobility extentions, locator", + doi="10.17487/RFC5206", + } + +@misc{rfc5207, + author="M. Stiemerling and J. Quittek and L. Eggert", + title="{NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication}", + howpublished="RFC 5207 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5207", + pages="1--13", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5207.txt", + key="RFC 5207", + abstract={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 sp ecifications 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.}, + keywords="HIP, host identity protocol, host identity payload, NAT traversal, middlebox traversal, firewall traversal, ID locator split, problem statement", + doi="10.17487/RFC5207", + } + +@misc{rfc5208, + author="B. Kaliski", + title="{Public-Key Cryptography Standards (PKCS) \#8: Private-Key Information Syntax Specification Version 1.2}", + howpublished="RFC 5208 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5208", + pages="1--8", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5958", +url="https://www.rfc-editor.org/rfc/rfc5208.txt", + key="RFC 5208", + abstract={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. This document describes a syntax for private-key information. This memo provides information for the Internet community.}, + keywords="rsa laboratories, private-key syntax, change control", + doi="10.17487/RFC5208", + } + +@misc{rfc5209, + author="P. Sangster and H. Khosravi and M. Mani and K. Narayan and J. Tardo", + title="{Network Endpoint Assessment (NEA): Overview and Requirements}", + howpublished="RFC 5209 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5209", + pages="1--53", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5209.txt", + key="RFC 5209", + abstract={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.}, + keywords="Posture, Remediation, reassessment, Validator, Collector, Broker, compliance, privacy, disclosure, replay, trust, policy", + doi="10.17487/RFC5209", + } + +@misc{rfc5210, + author="J. Wu and J. Bi and X. Li and G. Ren and K. Xu and M. Williams", + title="{A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience}", + howpublished="RFC 5210 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5210", + pages="1--25", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5210.txt", + key="RFC 5210", + abstract={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.}, + keywords="Source Address Validation, Source Addressing Spoofing, Network Security, Testbed, IPv6", + doi="10.17487/RFC5210", + } + +@misc{rfc5211, + author="J. Curran", + title="{An Internet Transition Plan}", + howpublished="RFC 5211 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5211", + pages="1--8", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5211.txt", + key="RFC 5211", + abstract={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.}, + doi="10.17487/RFC5211", + } + +@misc{rfc5212, + author="K. Shiomoto and D. Papadimitriou and JL. Le Roux and M. Vigoureux and D. Brungard", + title="{Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)}", + howpublished="RFC 5212 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5212", + pages="1--28", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5212.txt", + key="RFC 5212", + abstract={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. 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.}, + keywords="generalized mpls, switching technology", + doi="10.17487/RFC5212", + } + +@misc{rfc5213, + author="S. {Gundavelli (Ed.)} and K. Leung and V. Devarapalli and K. Chowdhury and B. Patil", + title="{Proxy Mobile IPv6}", + howpublished="RFC 5213 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5213", + pages="1--92", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6543, 7864", +url="https://www.rfc-editor.org/rfc/rfc5213.txt", + key="RFC 5213", + abstract={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]}, + keywords="mobility management", + doi="10.17487/RFC5213", + } + +@misc{rfc5214, + author="F. Templin and T. Gleeson and D. Thaler", + title="{Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)}", + howpublished="RFC 5214 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5214", + pages="1--15", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5214.txt", + key="RFC 5214", + abstract={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.}, + keywords="ipv6, ipv4, non-broadcast multiple access, nbma, dual-stack", + doi="10.17487/RFC5214", + } + +@misc{rfc5215, + author="L. Barbato", + title="{RTP Payload Format for Vorbis Encoded Audio}", + howpublished="RFC 5215 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5215", + pages="1--26", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5215.txt", + key="RFC 5215", + abstract={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. 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]}, + keywords="realtime transport protocol, codebook", + doi="10.17487/RFC5215", + } + +@misc{rfc5216, + author="D. Simon and B. Aboba and R. Hurst", + title="{The EAP-TLS Authentication Protocol}", + howpublished="RFC 5216 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5216", + pages="1--34", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5216.txt", + key="RFC 5216", + abstract={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. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]}, + keywords="extensible authentication protocol, point-to-point, link control compression, extensible, transport level security", + doi="10.17487/RFC5216", + } + +@misc{rfc5217, + author="M. {Shimaoka (Ed.)} and N. Hastings and R. Nielsen", + title="{Memorandum for Multi-Domain Public Key Infrastructure Interoperability}", + howpublished="RFC 5217 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5217", + pages="1--29", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5217.txt", + key="RFC 5217", + abstract={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.}, + keywords="pki, multi-domain pki, pki domain", + doi="10.17487/RFC5217", + } + +@misc{rfc5218, + author="D. Thaler and B. Aboba", + title="{What Makes for a Successful Protocol?}", + howpublished="RFC 5218 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5218", + pages="1--28", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5218.txt", + key="RFC 5218", + abstract={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.}, + doi="10.17487/RFC5218", + } + +@misc{rfc5219, + author="R. Finlayson", + title="{A More Loss-Tolerant RTP Payload Format for MP3 Audio}", + howpublished="RFC 5219 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5219", + pages="1--22", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5219.txt", + key="RFC 5219", + abstract={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]}, + keywords="real time protocol, real-time protocol, mpeg, moving picture experts group,", + doi="10.17487/RFC5219", + } + +@misc{rfc5220, + author="A. Matsumoto and T. Fujisaki and R. Hiromi and K. Kanayama", + title="{Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules}", + howpublished="RFC 5220 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5220", + pages="1--17", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5220.txt", + key="RFC 5220", + abstract={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.}, + keywords="multiple prefixes", + doi="10.17487/RFC5220", + } + +@misc{rfc5221, + author="A. Matsumoto and T. Fujisaki and R. Hiromi and K. Kanayama", + title="{Requirements for Address Selection Mechanisms}", + howpublished="RFC 5221 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5221", + pages="1--7", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5221.txt", + key="RFC 5221", + abstract={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.}, + keywords="default address selection", + doi="10.17487/RFC5221", + } + +@misc{rfc5222, + author="T. Hardie and A. Newton and H. Schulzrinne and H. Tschofenig", + title="{LoST: A Location-to-Service Translation Protocol}", + howpublished="RFC 5222 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5222", + pages="1--69", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6848", +url="https://www.rfc-editor.org/rfc/rfc5222.txt", + key="RFC 5222", + abstract={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]}, + keywords="emergency services, emergency call routing", + doi="10.17487/RFC5222", + } + +@misc{rfc5223, + author="H. Schulzrinne and J. Polk and H. Tschofenig", + title="{Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)}", + howpublished="RFC 5223 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5223", + pages="1--8", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5223.txt", + key="RFC 5223", + abstract={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. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). [STANDARDS-TRACK]}, + keywords="mapping service, emergency service, emergency communication", + doi="10.17487/RFC5223", + } + +@misc{rfc5224, + author="M. Brenner", + title="{Diameter Policy Processing Application}", + howpublished="RFC 5224 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5224", + pages="1--5", + year=2008, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5224.txt", + key="RFC 5224", + abstract={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.}, + keywords="policy evaluation, or evaluation and enforcement, pem-1, peem, oma, open mobile alliance", + doi="10.17487/RFC5224", + } + +@misc{rfc5225, + author="G. Pelletier and K. Sandlund", + title="{RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite}", + howpublished="RFC 5225 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5225", + pages="1--124", + year=2008, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5225.txt", + key="RFC 5225", + abstract={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. 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. 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]}, + keywords="rohc, 3095, 3843, 4019", + doi="10.17487/RFC5225", + } + +@misc{rfc5226, + author="T. Narten and H. Alvestrand", + title="{Guidelines for Writing an IANA Considerations Section in RFCs}", + howpublished="RFC 5226 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5226", + pages="1--27", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8126", +url="https://www.rfc-editor.org/rfc/rfc5226.txt", + key="RFC 5226", + abstract={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). 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. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.}, + keywords="internet assigned numbers authority, values, implementations, code point, protocol constant, protocol parameter", + doi="10.17487/RFC5226", + } + +@misc{rfc5227, + author="S. Cheshire", + title="{IPv4 Address Conflict Detection}", + howpublished="RFC 5227 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5227", + pages="1--21", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5227.txt", + key="RFC 5227", + abstract={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]}, + keywords="internet protocol version 4", + doi="10.17487/RFC5227", + } + +@misc{rfc5228, + author="P. {Guenther (Ed.)} and T. {Showalter (Ed.)}", + title="{Sieve: An Email Filtering Language}", + howpublished="RFC 5228 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5228", + pages="1--42", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5229, 5429, 6785", +url="https://www.rfc-editor.org/rfc/rfc5228.txt", + key="RFC 5228", + abstract={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]}, + keywords="", + doi="10.17487/RFC5228", + } + +@misc{rfc5229, + author="K. Homme", + title="{Sieve Email Filtering: Variables Extension}", + howpublished="RFC 5229 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5229", + pages="1--11", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5173", +url="https://www.rfc-editor.org/rfc/rfc5229.txt", + key="RFC 5229", + abstract={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]}, + keywords="", + doi="10.17487/RFC5229", + } + +@misc{rfc5230, + author="T. Showalter and N. {Freed (Ed.)}", + title="{Sieve Email Filtering: Vacation Extension}", + howpublished="RFC 5230 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5230", + pages="1--16", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5230.txt", + key="RFC 5230", + abstract={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]}, + keywords="autoresponder", + doi="10.17487/RFC5230", + } + +@misc{rfc5231, + author="W. Segmuller and B. Leiba", + title="{Sieve Email Filtering: Relational Extension}", + howpublished="RFC 5231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5231", + pages="1--9", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5231.txt", + key="RFC 5231", + abstract={This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. This document obsoletes RFC 3431. [STANDARDS-TRACK]}, + keywords="relational operators", + doi="10.17487/RFC5231", + } + +@misc{rfc5232, + author="A. Melnikov", + title="{Sieve Email Filtering: Imap4flags Extension}", + howpublished="RFC 5232 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5232", + pages="1--12", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5232.txt", + key="RFC 5232", + abstract={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. 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]}, + keywords="imap, internet message access control protocol, imap flags, imap system flags, imap keywords", + doi="10.17487/RFC5232", + } + +@misc{rfc5233, + author="K. Murchison", + title="{Sieve Email Filtering: Subaddress Extension}", + howpublished="RFC 5233 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5233", + pages="1--7", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5233.txt", + key="RFC 5233", + abstract={On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., ``ken+sieve(a)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]}, + keywords="subaddressing, detailed addressing, :user, :detail", + doi="10.17487/RFC5233", + } + +@misc{rfc5234, + author="D. {Crocker (Ed.)} and P. Overell", + title="{Augmented BNF for Syntax Specifications: ABNF}", + howpublished="RFC 5234 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5234", + pages="1--16", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7405", +url="https://www.rfc-editor.org/rfc/rfc5234.txt", + key="RFC 5234", + abstract={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]}, + keywords="ABNF, backus-naur form, augmented backus-naur form, rule definitions, encoding, core lexical analyzer", + doi="10.17487/RFC5234", + } + +@misc{rfc5235, + author="C. Daboo", + title="{Sieve Email Filtering: Spamtest and Virustest Extensions}", + howpublished="RFC 5235 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5235", + pages="1--13", + year=2008, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5235.txt", + key="RFC 5235", + abstract={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]}, + keywords="spamtest, spamtestplus, virustest, scores", + doi="10.17487/RFC5235", + } + +@misc{rfc5236, + author="A. Jayasumana and N. Piratla and T. Banka and A. Bare and R. Whitner", + title="{Improved Packet Reordering Metrics}", + howpublished="RFC 5236 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5236", + pages="1--26", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5236.txt", + key="RFC 5236", + abstract={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. 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.}, + keywords="reorder density, rd, reorder buffer-occupancy density, rbd", + doi="10.17487/RFC5236", + } + +@misc{rfc5237, + author="J. Arkko and S. Bradner", + title="{IANA Allocation Guidelines for the Protocol Field}", + howpublished="RFC 5237 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5237", + pages="1--5", + year=2008, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5237.txt", + key="RFC 5237", + abstract={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.}, + keywords="ipv4 header, next header field, internet, assigned, numbers, authority, IP", + doi="10.17487/RFC5237", + } + +@misc{rfc5238, + author="T. Phelan", + title="{Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)}", + howpublished="RFC 5238 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5238", + pages="1--10", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5238.txt", + key="RFC 5238", + abstract={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]}, + keywords="tls, transport protocol", + doi="10.17487/RFC5238", + } + +@misc{rfc5239, + author="M. Barnes and C. Boulton and O. Levin", + title="{A Framework for Centralized Conferencing}", + howpublished="RFC 5239 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5239", + pages="1--57", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5239.txt", + key="RFC 5239", + abstract={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]}, + keywords="call signaling, call signalling", + doi="10.17487/RFC5239", + } + +@misc{rfc5240, + author="B. Joshi and R. Bijlani", + title="{Protocol Independent Multicast (PIM) Bootstrap Router MIB}", + howpublished="RFC 5240 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5240", + pages="1--23", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5240.txt", + key="RFC 5240", + abstract={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]}, + keywords="management information base, bootstrap router, bsr, PIM-BSR-MIB", + doi="10.17487/RFC5240", + } + +@misc{rfc5241, + author="A. Falk and S. Bradner", + title="{Naming Rights in IETF Protocols}", + howpublished="RFC 5241 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5241", + pages="1--12", + year=2008, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5241.txt", + key="RFC 5241", + abstract={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.}, + keywords="april fools, field naming rights", + doi="10.17487/RFC5241", + } + +@misc{rfc5242, + author="J. Klensin and H. Alvestrand", + title="{A Generalized Unified Character Code: Western European and CJK Sections}", + howpublished="RFC 5242 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5242", + pages="1--14", + year=2008, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5242.txt", + key="RFC 5242", + abstract={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.}, + keywords="idn, latin, greek, cyrilllic, chinese, internationalized domain names", + doi="10.17487/RFC5242", + } + +@misc{rfc5243, + author="R. Ogier", + title="{OSPF Database Exchange Summary List Optimization}", + howpublished="RFC 5243 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5243", + pages="1--5", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5243.txt", + key="RFC 5243", + abstract={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.}, + doi="10.17487/RFC5243", + } + +@misc{rfc5244, + author="H. Schulzrinne and T. Taylor", + title="{Definition of Events for Channel-Oriented Telephony Signalling}", + howpublished="RFC 5244 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5244", + pages="1--23", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5244.txt", + key="RFC 5244", + abstract={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]}, + keywords="event code, telephony event rtp payload", + doi="10.17487/RFC5244", + } + +@misc{rfc5245, + author="J. Rosenberg", + title="{Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols}", + howpublished="RFC 5245 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5245", + pages="1--117", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8445, updated by RFC 6336", +url="https://www.rfc-editor.org/rfc/rfc5245.txt", + key="RFC 5245", + abstract={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]}, + keywords="", + doi="10.17487/RFC5245", + } + +@misc{rfc5246, + author="T. Dierks and E. Rescorla", + title="{The Transport Layer Security (TLS) Protocol Version 1.2}", + howpublished="RFC 5246 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5246", + pages="1--104", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8446, updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685, 7905, 7919, 8447", +url="https://www.rfc-editor.org/rfc/rfc5246.txt", + key="RFC 5246", + abstract={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]}, + keywords="idea, international data algorithm, symmetric, transport protocol layer, authentication, privacy", + doi="10.17487/RFC5246", + } + +@misc{rfc5247, + author="B. Aboba and D. Simon and P. Eronen", + title="{Extensible Authentication Protocol (EAP) Key Management Framework}", + howpublished="RFC 5247 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5247", + pages="1--79", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5247.txt", + key="RFC 5247", + abstract={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]}, + keywords="extensible network access authentication, key hierarchy, methods", + doi="10.17487/RFC5247", + } + +@misc{rfc5248, + author="T. Hansen and J. Klensin", + title="{A Registry for SMTP Enhanced Mail System Status Codes}", + howpublished="RFC 5248 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5248", + pages="1--11", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5248.txt", + key="RFC 5248", + abstract={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.}, + keywords="simple mail transfer protocol", + doi="10.17487/RFC5248", + } + +@misc{rfc5249, + author="D. {Harrington (Ed.)}", + title="{Templates for Internet-Drafts Containing MIB Modules}", + howpublished="RFC 5249 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5249", + pages="1--4", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5249.txt", + key="RFC 5249", + abstract={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.}, + keywords="network management, management information base, mib, smiv2, template", + doi="10.17487/RFC5249", + } + +@misc{rfc5250, + author="L. Berger and I. Bryskin and A. Zinin and R. Coltun", + title="{The OSPF Opaque LSA Option}", + howpublished="RFC 5250 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5250", + pages="1--17", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5250.txt", + key="RFC 5250", + abstract={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. 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]}, + keywords="OSPF-LSA], open shortest path first, link state advertisement, opaque lsas", + doi="10.17487/RFC5250", + } + +@misc{rfc5251, + author="D. {Fedyk (Ed.)} and Y. {Rekhter (Ed.)} and D. Papadimitriou and R. Rabbat and L. Berger", + title="{Layer 1 VPN Basic Mode}", + howpublished="RFC 5251 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5251", + pages="1--24", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5251.txt", + key="RFC 5251", + abstract={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]}, + keywords="virtual private network, l1vpn, l1vpn bm", + doi="10.17487/RFC5251", + } + +@misc{rfc5252, + author="I. Bryskin and L. Berger", + title="{OSPF-Based Layer 1 VPN Auto-Discovery}", + howpublished="RFC 5252 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5252", + pages="1--11", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5252.txt", + key="RFC 5252", + abstract={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]}, + keywords="open shortest path first, l1vpn, layer 1 virtual private network", + doi="10.17487/RFC5252", + } + +@misc{rfc5253, + author="T. {Takeda (Ed.)}", + title="{Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode}", + howpublished="RFC 5253 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5253", + pages="1--19", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5253.txt", + key="RFC 5253", + abstract={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). 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.}, + keywords="gmpls, generalized multiprotocol label switching, l1vpn bm", + doi="10.17487/RFC5253", + } + +@misc{rfc5254, + author="N. {Bitar (Ed.)} and M. {Bocci (Ed.)} and L. {Martini (Ed.)}", + title="{Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)}", + howpublished="RFC 5254 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5254", + pages="1--27", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5254.txt", + key="RFC 5254", + abstract={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.}, + keywords="Pseudowire, PWE3, multi-segment, MS-PW, SS-PW, S-PE, T-PE", + doi="10.17487/RFC5254", + } + +@misc{rfc5255, + author="C. Newman and A. Gulbrandsen and A. Melnikov", + title="{Internet Message Access Protocol Internationalization}", + howpublished="RFC 5255 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5255", + pages="1--20", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5255.txt", + key="RFC 5255", + abstract={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]}, + keywords="imap, imapv4, imap4", + doi="10.17487/RFC5255", + } + +@misc{rfc5256, + author="M. Crispin and K. Murchison", + title="{Internet Message Access Protocol - SORT and THREAD Extensions}", + howpublished="RFC 5256 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5256", + pages="1--19", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5957", +url="https://www.rfc-editor.org/rfc/rfc5256.txt", + key="RFC 5256", + abstract={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]}, + keywords="ordered subject references, imap capability", + doi="10.17487/RFC5256", + } + +@misc{rfc5257, + author="C. Daboo and R. Gellens", + title="{Internet Message Access Protocol - ANNOTATE Extension}", + howpublished="RFC 5257 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5257", + pages="1--31", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5257.txt", + key="RFC 5257", + abstract={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. 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. 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.}, + keywords="imap", + doi="10.17487/RFC5257", + } + +@misc{rfc5258, + author="B. Leiba and A. Melnikov", + title="{Internet Message Access Protocol version 4 - LIST Command Extensions}", + howpublished="RFC 5258 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5258", + pages="1--31", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5258.txt", + key="RFC 5258", + abstract={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]}, + keywords="imap4 ,list, lsub, extended list, email", + doi="10.17487/RFC5258", + } + +@misc{rfc5259, + author="A. {Melnikov (Ed.)} and P. {Coates (Ed.)}", + title="{Internet Message Access Protocol - CONVERT Extension}", + howpublished="RFC 5259 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5259", + pages="1--30", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5259.txt", + key="RFC 5259", + abstract={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]}, + keywords="IMAP, Lemonade, CONVERT, conversion, transcoding", + doi="10.17487/RFC5259", + } + +@misc{rfc5260, + author="N. Freed", + title="{Sieve Email Filtering: Date and Index Extensions}", + howpublished="RFC 5260 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5260", + pages="1--13", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5260.txt", + key="RFC 5260", + abstract={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]}, + keywords="smtp, esmtp, date, index", + doi="10.17487/RFC5260", + } + +@misc{rfc5261, + author="J. Urpalainen", + title="{An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors}", + howpublished="RFC 5261 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5261", + pages="1--40", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5261.txt", + key="RFC 5261", + abstract={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 \<add\>, \<replace\>, and \<remove\> directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5261", + } + +@misc{rfc5262, + author="M. Lonnfors and E. Leppanen and H. Khartabil and J. Urpalainen", + title="{Presence Information Data Format (PIDF) Extension for Partial Presence}", + howpublished="RFC 5262 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5262", + pages="1--16", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5262.txt", + key="RFC 5262", + abstract={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]}, + keywords="", + doi="10.17487/RFC5262", + } + +@misc{rfc5263, + author="M. Lonnfors and J. Costa-Requena and E. Leppanen and H. Khartabil", + title="{Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information}", + howpublished="RFC 5263 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5263", + pages="1--16", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5263.txt", + key="RFC 5263", + abstract={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]}, + keywords="pidf, presence information data format", + doi="10.17487/RFC5263", + } + +@misc{rfc5264, + author="A. Niemi and M. Lonnfors and E. Leppanen", + title="{Publication of Partial Presence Information}", + howpublished="RFC 5264 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5264", + pages="1--15", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5264.txt", + key="RFC 5264", + abstract={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]}, + keywords="", + doi="10.17487/RFC5264", + } + +@misc{rfc5265, + author="S. Vaarala and E. Klovning", + title="{Mobile IPv4 Traversal across IPsec-Based VPN Gateways}", + howpublished="RFC 5265 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5265", + pages="1--39", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5265.txt", + key="RFC 5265", + abstract={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]}, + keywords="mobile ip, mobile ipv4, ipsec, mipv4", + doi="10.17487/RFC5265", + } + +@misc{rfc5266, + author="V. Devarapalli and P. Eronen", + title="{Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)}", + howpublished="RFC 5266 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5266", + pages="1--15", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5266.txt", + key="RFC 5266", + abstract={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.}, + keywords="", + doi="10.17487/RFC5266", + } + +@misc{rfc5267, + author="D. Cridland and C. King", + title="{Contexts for IMAP4}", + howpublished="RFC 5267 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5267", + pages="1--18", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5465", +url="https://www.rfc-editor.org/rfc/rfc5267.txt", + key="RFC 5267", + abstract={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]}, + keywords="imap4rev1, esort, context", + doi="10.17487/RFC5267", + } + +@misc{rfc5268, + author="R. {Koodli (Ed.)}", + title="{Mobile IPv6 Fast Handovers}", + howpublished="RFC 5268 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5268", + pages="1--48", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5568", +url="https://www.rfc-editor.org/rfc/rfc5268.txt", + key="RFC 5268", + abstract={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]}, + keywords="mipv6, handover latency", + doi="10.17487/RFC5268", + } + +@misc{rfc5269, + author="J. Kempf and R. Koodli", + title="{Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)}", + howpublished="RFC 5269 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5269", + pages="1--14", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5269.txt", + key="RFC 5269", + abstract={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 hav e 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]}, + keywords="fast binding update", + doi="10.17487/RFC5269", + } + +@misc{rfc5270, + author="H. Jang and J. Jee and Y. Han and S. Park and J. Cha", + title="{Mobile IPv6 Fast Handovers over IEEE 802.16e Networks}", + howpublished="RFC 5270 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5270", + pages="1--18", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5270.txt", + key="RFC 5270", + abstract={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.}, + keywords="Mobile IPv6, Handover optimization, Cross-layer design", + doi="10.17487/RFC5270", + } + +@misc{rfc5271, + author="H. Yokota and G. Dommety", + title="{Mobile IPv6 Fast Handovers for 3G CDMA Networks}", + howpublished="RFC 5271 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5271", + pages="1--22", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5271.txt", + key="RFC 5271", + abstract={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.}, + keywords="FMIP, handoff, 3GPP2", + doi="10.17487/RFC5271", + } + +@misc{rfc5272, + author="J. Schaad and M. Myers", + title="{Certificate Management over CMS (CMC)}", + howpublished="RFC 5272 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5272", + pages="1--83", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6402", +url="https://www.rfc-editor.org/rfc/rfc5272.txt", + key="RFC 5272", + abstract={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: 1. The need for an interface to public key certification products and services based on CMS and PKCS \#10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]}, + keywords="certificate management protocol, cryptographic message syntax, pki, public key infrastructure", + doi="10.17487/RFC5272", + } + +@misc{rfc5273, + author="J. Schaad and M. Myers", + title="{Certificate Management over CMS (CMC): Transport Protocols}", + howpublished="RFC 5273 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5273", + pages="1--7", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6402", +url="https://www.rfc-editor.org/rfc/rfc5273.txt", + key="RFC 5273", + abstract={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]}, + keywords="cryptographic message syntax, http, file, mail, tcp", + doi="10.17487/RFC5273", + } + +@misc{rfc5274, + author="J. Schaad and M. Myers", + title="{Certificate Management Messages over CMS (CMC): Compliance Requirements}", + howpublished="RFC 5274 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5274", + pages="1--13", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6402", +url="https://www.rfc-editor.org/rfc/rfc5274.txt", + key="RFC 5274", + abstract={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]}, + keywords="cryptographic message syntax, cmc enrollment protocol", + doi="10.17487/RFC5274", + } + +@misc{rfc5275, + author="S. Turner", + title="{CMS Symmetric Key Management and Distribution}", + howpublished="RFC 5275 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5275", + pages="1--89", + year=2008, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5275.txt", + key="RFC 5275", + abstract={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]}, + keywords="cryptographic message syntax, symmetric cryptographic algorithms, certificate management over cms, cmc", + doi="10.17487/RFC5275", + } + +@misc{rfc5276, + author="C. Wallace", + title="{Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records}", + howpublished="RFC 5276 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5276", + pages="1--13", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5276.txt", + key="RFC 5276", + abstract={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]}, + keywords="ERS, Evidence Record, SCVP, Server-based Certificate Validation Protocol, PKI artifact preservation", + doi="10.17487/RFC5276", + } + +@misc{rfc5277, + author="S. Chisholm and H. Trevino", + title="{NETCONF Event Notifications}", + howpublished="RFC 5277 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5277", + pages="1--35", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5277.txt", + key="RFC 5277", + abstract={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]}, + keywords="XML, Extensible Markup Language, NETCONF, Event, Asynchronous Message, Notification", + doi="10.17487/RFC5277", + } + +@misc{rfc5278, + author="J. Livingood and D. Troshynski", + title="{IANA Registration of Enumservices for Voice and Video Messaging}", + howpublished="RFC 5278 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5278", + pages="1--22", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc5278.txt", + key="RFC 5278", + abstract={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]}, + keywords="vmsg, voicemsg, videomsg, unifmsg, sip, sips, http, https, tel", + doi="10.17487/RFC5278", + } + +@misc{rfc5279, + author="A. Monrad and S. Loreto", + title="{A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)}", + howpublished="RFC 5279 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5279", + pages="1--7", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5279.txt", + key="RFC 5279", + abstract={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.}, + keywords="nid, namespace identifier, 3gpp", + doi="10.17487/RFC5279", + } + +@misc{rfc5280, + author="D. Cooper and S. Santesson and S. Farrell and S. Boeyen and R. Housley and W. Polk", + title="{Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}", + howpublished="RFC 5280 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5280", + pages="1--151", + year=2008, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6818, 8398, 8399", +url="https://www.rfc-editor.org/rfc/rfc5280.txt", + key="RFC 5280", + abstract={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]}, + keywords="X.509 v3, X.509 v2, certificate extensions", + doi="10.17487/RFC5280", + } + +@misc{rfc5281, + author="P. Funk and S. Blake-Wilson", + title="{Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)}", + howpublished="RFC 5281 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5281", + pages="1--51", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5281.txt", + key="RFC 5281", + abstract={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.}, + keywords="EAP, AAA, Authentication, TLS", + doi="10.17487/RFC5281", + } + +@misc{rfc5282, + author="D. Black and D. McGrew", + title="{Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol}", + howpublished="RFC 5282 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5282", + pages="1--19", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5282.txt", + key="RFC 5282", + abstract={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. 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]}, + keywords="encryption cipher, combined mode algorithms, aes gcm, advanced encryption standard in galois/counter mode, aes ccm, aes in couner with cbc-mac mode", + doi="10.17487/RFC5282", + } + +@misc{rfc5283, + author="B. Decraene and JL. Le Roux and I. Minei", + title="{LDP Extension for Inter-Area Label Switched Paths (LSPs)}", + howpublished="RFC 5283 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5283", + pages="1--12", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5283.txt", + key="RFC 5283", + abstract={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). 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]}, + keywords="LDP label mapping procedures, longest-match, prefix aggregation", + doi="10.17487/RFC5283", + } + +@misc{rfc5284, + author="G. Swallow and A. Farrel", + title="{User-Defined Errors for RSVP}", + howpublished="RFC 5284 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5284", + pages="1--9", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5284.txt", + key="RFC 5284", + abstract={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. 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]}, + keywords="resource reservation protocol, user\_error\_spec, error\_spec", + doi="10.17487/RFC5284", + } + +@misc{rfc5285, + author="D. Singer and H. Desineni", + title="{A General Mechanism for RTP Header Extensions}", + howpublished="RFC 5285 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5285", + pages="1--17", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8285", +url="https://www.rfc-editor.org/rfc/rfc5285.txt", + key="RFC 5285", + abstract={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]}, + keywords="real-time transport protocol, extmap", + doi="10.17487/RFC5285", + } + +@misc{rfc5286, + author="A. {Atlas (Ed.)} and A. {Zinin (Ed.)}", + title="{Basic Specification for IP Fast Reroute: Loop-Free Alternates}", + howpublished="RFC 5286 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5286", + pages="1--31", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5286.txt", + key="RFC 5286", + abstract={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]}, + keywords="FRR, LFA, recovery, failure, routing", + doi="10.17487/RFC5286", + } + +@misc{rfc5287, + author="A. Vainshtein and Y(J). Stein", + title="{Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks}", + howpublished="RFC 5287 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5287", + pages="1--16", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5287.txt", + key="RFC 5287", + abstract={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]}, + keywords="pwe3, pseudowire emulation edge-to-edge, tdmoip, tdm options", + doi="10.17487/RFC5287", + } + +@misc{rfc5288, + author="J. Salowey and A. Choudhury and D. McGrew", + title="{AES Galois Counter Mode (GCM) Cipher Suites for TLS}", + howpublished="RFC 5288 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5288", + pages="1--8", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5288.txt", + key="RFC 5288", + abstract={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]}, + keywords="advanced encryption standard, transport layer security, data origin, confidentiality", + doi="10.17487/RFC5288", + } + +@misc{rfc5289, + author="E. Rescorla", + title="{TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)}", + howpublished="RFC 5289 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5289", + pages="1--6", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5289.txt", + key="RFC 5289", + abstract={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.}, + keywords="transport layer security, mac algorithm", + doi="10.17487/RFC5289", + } + +@misc{rfc5290, + author="S. Floyd and M. Allman", + title="{Comments on the Usefulness of Simple Best-Effort Traffic}", + howpublished="RFC 5290 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5290", + pages="1--20", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5290.txt", + key="RFC 5290", + abstract={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.}, + keywords="flow-rate fairness", + doi="10.17487/RFC5290", + } + +@misc{rfc5291, + author="E. Chen and Y. Rekhter", + title="{Outbound Route Filtering Capability for BGP-4}", + howpublished="RFC 5291 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5291", + pages="1--12", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5291.txt", + key="RFC 5291", + abstract={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]}, + keywords="border gatway protocol, orf", + doi="10.17487/RFC5291", + } + +@misc{rfc5292, + author="E. Chen and S. Sangli", + title="{Address-Prefix-Based Outbound Route Filter for BGP-4}", + howpublished="RFC 5292 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5292", + pages="1--6", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5292.txt", + key="RFC 5292", + abstract={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]}, + keywords="orf, border gateway protocol, Address Prefix Outbound Route Filter", + doi="10.17487/RFC5292", + } + +@misc{rfc5293, + author="J. Degener and P. Guenther", + title="{Sieve Email Filtering: Editheader Extension}", + howpublished="RFC 5293 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5293", + pages="1--9", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5293.txt", + key="RFC 5293", + abstract={This document defines two new actions for the ``Sieve'' email filtering language that add and delete email header fields. [STANDARDS-TRACK]}, + keywords="addheadaer, deleteheader", + doi="10.17487/RFC5293", + } + +@misc{rfc5294, + author="P. Savola and J. Lingard", + title="{Host Threats to Protocol Independent Multicast (PIM)}", + howpublished="RFC 5294 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5294", + pages="1--12", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5294.txt", + key="RFC 5294", + abstract={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.}, + keywords="security threat analysis", + doi="10.17487/RFC5294", + } + +@misc{rfc5295, + author="J. Salowey and L. Dondeti and V. Narayanan and M. Nakhjiri", + title="{Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)}", + howpublished="RFC 5295 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5295", + pages="1--21", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5295.txt", + key="RFC 5295", + abstract={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]}, + keywords="EAP keying, EMSK, DSRK, DSUSRK, Domain-Specific Key Derivation, Usage-Specific Key Derivation", + doi="10.17487/RFC5295", + } + +@misc{rfc5296, + author="V. Narayanan and L. Dondeti", + title="{EAP Extensions for EAP Re-authentication Protocol (ERP)}", + howpublished="RFC 5296 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5296", + pages="1--43", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6696", +url="https://www.rfc-editor.org/rfc/rfc5296.txt", + key="RFC 5296", + abstract={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]}, + keywords="extensible authentication protocol, authentication modes", + doi="10.17487/RFC5296", + } + +@misc{rfc5297, + author="D. Harkins", + title="{Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)}", + howpublished="RFC 5297 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5297", + pages="1--26", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5297.txt", + key="RFC 5297", + abstract={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.}, + keywords="authenticated encryption, key wrapping, key derivation, block cipher, pseudo-random function", + doi="10.17487/RFC5297", + } + +@misc{rfc5298, + author="T. {Takeda (Ed.)} and A. {Farrel (Ed.)} and Y. Ikejiri and JP. Vasseur", + title="{Analysis of Inter-Domain Label Switched Path (LSP) Recovery}", + howpublished="RFC 5298 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5298", + pages="1--26", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5298.txt", + key="RFC 5298", + abstract={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. 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''. 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.}, + keywords="mpls, gmpls, multi-domain environment, end-to-end diverse Traffic Engineering LSPs", + doi="10.17487/RFC5298", + } + +@misc{rfc5301, + author="D. McPherson and N. Shen", + title="{Dynamic Hostname Exchange Mechanism for IS-IS}", + howpublished="RFC 5301 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5301", + pages="1--6", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6232", +url="https://www.rfc-editor.org/rfc/rfc5301.txt", + key="RFC 5301", + abstract={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. This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]}, + keywords="intermediate system to intermediate system, routers, tlv, name-to-systemID", + doi="10.17487/RFC5301", + } + +@misc{rfc5302, + author="T. Li and H. Smit and T. Przygienda", + title="{Domain-Wide Prefix Distribution with Two-Level IS-IS}", + howpublished="RFC 5302 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5302", + pages="1--16", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5302.txt", + key="RFC 5302", + abstract={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. 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]}, + keywords="intermediate system to intermediate system, routers, loops, IP, internet protocol", + doi="10.17487/RFC5302", + } + +@misc{rfc5303, + author="D. Katz and R. Saluja and D. {Eastlake 3rd}", + title="{Three-Way Handshake for IS-IS Point-to-Point Adjacencies}", + howpublished="RFC 5303 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5303", + pages="1--11", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5303.txt", + key="RFC 5303", + abstract={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. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. 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]}, + keywords="intermediate system to intermediate system", + doi="10.17487/RFC5303", + } + +@misc{rfc5304, + author="T. Li and R. Atkinson", + title="{IS-IS Cryptographic Authentication}", + howpublished="RFC 5304 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5304", + pages="1--11", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6233, 6232", +url="https://www.rfc-editor.org/rfc/rfc5304.txt", + key="RFC 5304", + abstract={This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. 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]}, + keywords="intermediate system to intermediate system, IS-IS authentication, MD5, HMAC-MD5, security, routing, iso, international standards organization", + doi="10.17487/RFC5304", + } + +@misc{rfc5305, + author="T. Li and H. Smit", + title="{IS-IS Extensions for Traffic Engineering}", + howpublished="RFC 5305 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5305", + pages="1--17", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5307", +url="https://www.rfc-editor.org/rfc/rfc5305.txt", + key="RFC 5305", + abstract={This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]}, + keywords="intermediate system to intermediate system, te, router, lsp data units, link state protocol data units", + doi="10.17487/RFC5305", + } + +@misc{rfc5306, + author="M. Shand and L. Ginsberg", + title="{Restart Signaling for IS-IS}", + howpublished="RFC 5306 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5306", + pages="1--22", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5306.txt", + key="RFC 5306", + abstract={This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved 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]}, + keywords="intermediate system to intermediate system, LSP database synchronization, Link State, Routing", + doi="10.17487/RFC5306", + } + +@misc{rfc5307, + author="K. {Kompella (Ed.)} and Y. {Rekhter (Ed.)}", + title="{IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)}", + howpublished="RFC 5307 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5307", + pages="1--12", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6001, 6002, 7074", +url="https://www.rfc-editor.org/rfc/rfc5307.txt", + key="RFC 5307", + abstract={This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]}, + keywords="intermediate system to intermediate system", + doi="10.17487/RFC5307", + } + +@misc{rfc5308, + author="C. Hopps", + title="{Routing IPv6 with IS-IS}", + howpublished="RFC 5308 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5308", + pages="1--7", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7775", +url="https://www.rfc-editor.org/rfc/rfc5308.txt", + key="RFC 5308", + abstract={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]}, + keywords="intermediate system to intermediate system, tlv, osi", + doi="10.17487/RFC5308", + } + +@misc{rfc5309, + author="N. {Shen (Ed.)} and A. {Zinin (Ed.)}", + title="{Point-to-Point Operation over LAN in Link State Routing Protocols}", + howpublished="RFC 5309 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5309", + pages="1--10", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5309.txt", + key="RFC 5309", + abstract={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.}, + keywords="broadcast", + doi="10.17487/RFC5309", + } + +@misc{rfc5310, + author="M. Bhatia and V. Manral and T. Li and R. Atkinson and R. White and M. Fanto", + title="{IS-IS Generic Cryptographic Authentication}", + howpublished="RFC 5310 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5310", + pages="1--12", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6233, 6232", +url="https://www.rfc-editor.org/rfc/rfc5310.txt", + key="RFC 5310", + abstract={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. 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]}, + keywords="IS-IS, Security, HMAC-SHA, Cryptographic Authentication", + doi="10.17487/RFC5310", + } + +@misc{rfc5311, + author="D. {McPherson (Ed.)} and L. Ginsberg and S. Previdi and M. Shand", + title="{Simplified Extension of Link State PDU (LSP) Space for IS-IS}", + howpublished="RFC 5311 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5311", + pages="1--12", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5311.txt", + key="RFC 5311", + abstract={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]}, + keywords="", + doi="10.17487/RFC5311", + } + +@misc{rfc5316, + author="M. Chen and R. Zhang and X. Duan", + title="{ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering}", + howpublished="RFC 5316 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5316", + pages="1--19", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5316.txt", + key="RFC 5316", + abstract={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. No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]}, + keywords="multiprotocol label switching, generalized mpls, gmpls-te, mpls-te, isis-te, flooding", + doi="10.17487/RFC5316", + } + +@misc{rfc5317, + author="S. {Bryant (Ed.)} and L. {Andersson (Ed.)}", + title="{Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile}", + howpublished="RFC 5317 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5317", + pages="1--10", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5317.txt", + key="RFC 5317", + abstract={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.}, + keywords="ITU-T, MPLS-TP, JWT, GMPLS, agreement, PWE3, OAM, transport network", + doi="10.17487/RFC5317", + } + +@misc{rfc5318, + author="J. Hautakorpi and G. Camarillo", + title="{The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)}", + howpublished="RFC 5318 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5318", + pages="1--12", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8217", +url="https://www.rfc-editor.org/rfc/rfc5318.txt", + key="RFC 5318", + abstract={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.}, + keywords="oma, open mobile alliance, push to talk over cellular, poc", + doi="10.17487/RFC5318", + } + +@misc{rfc5320, + author="F. {Templin (Ed.)}", + title="{The Subnetwork Encapsulation and Adaptation Layer (SEAL)}", + howpublished="RFC 5320 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5320", + pages="1--29", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5320.txt", + key="RFC 5320", + abstract={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.}, + keywords="virtual topologies, mtu, maximum transmission units", + doi="10.17487/RFC5320", + } + +@misc{rfc5321, + author="J. Klensin", + title="{Simple Mail Transfer Protocol}", + howpublished="RFC 5321 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5321", + pages="1--95", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7504", +url="https://www.rfc-editor.org/rfc/rfc5321.txt", + key="RFC 5321", + abstract={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]}, + keywords="SMTP]", + doi="10.17487/RFC5321", + } + +@misc{rfc5322, + author="P. {Resnick (Ed.)}", + title="{Internet Message Format}", + howpublished="RFC 5322 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5322", + pages="1--57", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6854", +url="https://www.rfc-editor.org/rfc/rfc5322.txt", + key="RFC 5322", + abstract={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]}, + keywords="MAIL], e-mail, email, electronic mail, header, address, mailbox, reply, forward, resend, resent, folding, Date, From, Sender, Reply-To, To, Cc, Bcc, Message-ID, In-Reply-To, References, Subject, Comments, Keywords, Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Bcc, Resent-Reply-To, Resent-Message-ID, Return-Path, Received", + doi="10.17487/RFC5322", + } + +@misc{rfc5323, + author="J. {Reschke (Ed.)} and S. Reddy and J. Davis and A. Babich", + title="{Web Distributed Authoring and Versioning (WebDAV) SEARCH}", + howpublished="RFC 5323 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5323", + pages="1--49", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5323.txt", + key="RFC 5323", + abstract={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]}, + keywords="HTTP, Query, Properties", + doi="10.17487/RFC5323", + } + +@misc{rfc5324, + author="C. DeSanti and F. Maino and K. McCloghrie", + title="{MIB for Fibre-Channel Security Protocols (FC-SP)}", + howpublished="RFC 5324 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5324", + pages="1--216", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5324.txt", + key="RFC 5324", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. [STANDARDS-TRACK]}, + keywords="management information base, T11-FC-SP-TC-MIB, T11-FC-SP-AUTHENTICATION-MIB, T11-FC-SP-ZONING-MIB, T11-FC-SP-POLICY-MIB, T11-FC-SP-SA-MIB", + doi="10.17487/RFC5324", + } + +@misc{rfc5325, + author="S. Burleigh and M. Ramadas and S. Farrell", + title="{Licklider Transmission Protocol - Motivation}", + howpublished="RFC 5325 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5325", + pages="1--23", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5325.txt", + key="RFC 5325", + abstract={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. 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. This document is a product of the Delay Tolerant Networking Research Group and has been re viewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.}, + keywords="ltp, round-trip times, long-haul", + doi="10.17487/RFC5325", + } + +@misc{rfc5326, + author="M. Ramadas and S. Burleigh and S. Farrell", + title="{Licklider Transmission Protocol - Specification}", + howpublished="RFC 5326 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5326", + pages="1--54", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5326.txt", + key="RFC 5326", + abstract={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. 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.}, + keywords="ltp, round-trip times, rtt, long-haul", + doi="10.17487/RFC5326", + } + +@misc{rfc5327, + author="S. Farrell and M. Ramadas and S. Burleigh", + title="{Licklider Transmission Protocol - Security Extensions}", + howpublished="RFC 5327 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5327", + pages="1--11", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5327.txt", + key="RFC 5327", + abstract={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. 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.}, + keywords="ltp, radio frequency, automatic repeat request, arq", + doi="10.17487/RFC5327", + } + +@misc{rfc5328, + author="A. Adolf and P. MacAvock", + title="{A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)}", + howpublished="RFC 5328 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5328", + pages="1--12", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7354", +url="https://www.rfc-editor.org/rfc/rfc5328.txt", + key="RFC 5328", + abstract={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.}, + keywords="tv, television, digital television, mpeg-2, iptv, multimedia, content guide, program guide, metadata", + doi="10.17487/RFC5328", + } + +@misc{rfc5329, + author="K. Ishiguro and V. Manral and A. Davey and A. {Lindem (Ed.)}", + title="{Traffic Engineering Extensions to OSPF Version 3}", + howpublished="RFC 5329 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5329", + pages="1--12", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5329.txt", + key="RFC 5329", + abstract={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]}, + keywords="open shortest path first, ospfv3, te", + doi="10.17487/RFC5329", + } + +@misc{rfc5330, + author="JP. {Vasseur (Ed.)} and M. Meyer and K. Kumaki and A. Bonda", + title="{A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link}", + howpublished="RFC 5330 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5330", + pages="1--8", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5330.txt", + key="RFC 5330", + abstract={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]}, + keywords="te, lsp", + doi="10.17487/RFC5330", + } + +@misc{rfc5331, + author="R. Aggarwal and Y. Rekhter and E. Rosen", + title="{MPLS Upstream Label Assignment and Context-Specific Label Space}", + howpublished="RFC 5331 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5331", + pages="1--13", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7274", +url="https://www.rfc-editor.org/rfc/rfc5331.txt", + key="RFC 5331", + abstract={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]}, + keywords="upstream-assigned mpls labels", + doi="10.17487/RFC5331", + } + +@misc{rfc5332, + author="T. Eckert and E. {Rosen (Ed.)} and R. Aggarwal and Y. Rekhter", + title="{MPLS Multicast Encapsulations}", + howpublished="RFC 5332 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5332", + pages="1--11", + year=2008, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5332.txt", + key="RFC 5332", + abstract={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''. 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. This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]}, + keywords="data link layer codepoint, multiaccess media, upstream-assigned label, mac da, medium access layer destination address", + doi="10.17487/RFC5332", + } + +@misc{rfc5333, + author="R. Mahy and B. Hoeneisen", + title="{IANA Registration of Enumservices for Internet Calendaring}", + howpublished="RFC 5333 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5333", + pages="1--8", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6118", +url="https://www.rfc-editor.org/rfc/rfc5333.txt", + key="RFC 5333", + abstract={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]}, + keywords="ENUM, iCal, iMIP, i TIP, CalDAV", + doi="10.17487/RFC5333", + } + +@misc{rfc5334, + author="I. Goncalves and S. Pfeiffer and C. Montgomery", + title="{Ogg Media Types}", + howpublished="RFC 5334 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5334", + pages="1--14", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7845", +url="https://www.rfc-editor.org/rfc/rfc5334.txt", + key="RFC 5334", + abstract={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]}, + keywords="Ogg, MIME, Video, Audio, Codecs", + doi="10.17487/RFC5334", + } + +@misc{rfc5335, + author="A. {Yang (Ed.)}", + title="{Internationalized Email Headers}", + howpublished="RFC 5335 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5335", + pages="1--14", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6532", +url="https://www.rfc-editor.org/rfc/rfc5335.txt", + key="RFC 5335", + abstract={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.}, + keywords="unicode, utf-8", + doi="10.17487/RFC5335", + } + +@misc{rfc5336, + author="J. {Yao (Ed.)} and W. {Mao (Ed.)}", + title="{SMTP Extension for Internationalized Email Addresses}", + howpublished="RFC 5336 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5336", + pages="1--22", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6531", +url="https://www.rfc-editor.org/rfc/rfc5336.txt", + key="RFC 5336", + abstract={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.}, + keywords="EAI, UTF8SMTP, MAIL, TRANSFER", + doi="10.17487/RFC5336", + } + +@misc{rfc5337, + author="C. Newman and A. {Melnikov (Ed.)}", + title="{Internationalized Delivery Status and Disposition Notifications}", + howpublished="RFC 5337 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5337", + pages="1--18", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6533", +url="https://www.rfc-editor.org/rfc/rfc5337.txt", + key="RFC 5337", + abstract={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. This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.}, + keywords="EAI, DSN, SMTP", + doi="10.17487/RFC5337", + } + +@misc{rfc5338, + author="T. Henderson and P. Nikander and M. Komu", + title="{Using the Host Identity Protocol with Legacy Applications}", + howpublished="RFC 5338 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5338", + pages="1--14", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5338.txt", + key="RFC 5338", + abstract={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.}, + keywords="hip, cryptographic name space, network stack names, api, application programming interface", + doi="10.17487/RFC5338", + } + +@misc{rfc5339, + author="JL. Le {Roux (Ed.)} and D. {Papadimitriou (Ed.)}", + title="{Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)}", + howpublished="RFC 5339 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5339", + pages="1--25", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5339.txt", + key="RFC 5339", + abstract={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.}, + keywords="general multiprotocol label switching", + doi="10.17487/RFC5339", + } + +@misc{rfc5340, + author="R. Coltun and D. Ferguson and J. Moy and A. Lindem", + title="{OSPF for IPv6}", + howpublished="RFC 5340 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5340", + pages="1--94", + year=2008, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6845, 6860, 7503, 8362", +url="https://www.rfc-editor.org/rfc/rfc5340.txt", + key="RFC 5340", + abstract={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). 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. Aut hentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). 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. 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]}, + keywords="open shortest path first, ospfv3", + doi="10.17487/RFC5340", + } + +@misc{rfc5341, + author="C. Jennings and V. Gurbani", + title="{The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry}", + howpublished="RFC 5341 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5341", + pages="1--7", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5341.txt", + key="RFC 5341", + abstract={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]}, + keywords="uniform resource locator, schemes", + doi="10.17487/RFC5341", + } + +@misc{rfc5342, + author="D. {Eastlake 3rd}", + title="{IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters}", + howpublished="RFC 5342 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5342", + pages="1--21", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7042", +url="https://www.rfc-editor.org/rfc/rfc5342.txt", + key="RFC 5342", + abstract={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.}, + keywords="Ethernet, Ethertype, 802, OUI, EUI, LSAP", + doi="10.17487/RFC5342", + } + +@misc{rfc5343, + author="J. Schoenwaelder", + title="{Simple Network Management Protocol (SNMP) Context EngineID Discovery}", + howpublished="RFC 5343 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5343", + pages="1--9", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5343.txt", + key="RFC 5343", + abstract={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. 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. This document updates RFC 3411. [STANDARDS-TRACK]}, + keywords="snmpv3, snmpengineid, localengineid", + doi="10.17487/RFC5343", + } + +@misc{rfc5344, + author="A. Houri and E. Aoki and S. Parameswar", + title="{Presence and Instant Messaging Peering Use Cases}", + howpublished="RFC 5344 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5344", + pages="1--9", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5344.txt", + key="RFC 5344", + abstract={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.}, + keywords="non-voip, collaboration service, instant messaging, im", + doi="10.17487/RFC5344", + } + +@misc{rfc5345, + author="J. Schoenwaelder", + title="{Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats}", + howpublished="RFC 5345 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5345", + pages="1--23", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5345.txt", + key="RFC 5345", + abstract={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. 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. 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.}, + keywords="large-scale snmp, irtf, nmrg, network management research group", + doi="10.17487/RFC5345", + } + +@misc{rfc5346, + author="J. Lim and W. Kim and C. Park and L. Conroy", + title="{Operational Requirements for ENUM-Based Softswitch Use}", + howpublished="RFC 5346 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5346", + pages="1--14", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5346.txt", + key="RFC 5346", + abstract={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. 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.}, + keywords="Applications, ENUM, DNS, E.164, NAPTR, Softswitch, Field Trial", + doi="10.17487/RFC5346", + } + +@misc{rfc5347, + author="F. Andreasen and D. Hancock", + title="{Media Gateway Control Protocol Fax Package}", + howpublished="RFC 5347 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5347", + pages="1--46", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5347.txt", + key="RFC 5347", + abstract={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.}, + keywords="mgcp, fax calls, fax relay, fax transmission", + doi="10.17487/RFC5347", + } + +@misc{rfc5348, + author="S. Floyd and M. Handley and J. Padhye and J. Widmer", + title="{TCP Friendly Rate Control (TFRC): Protocol Specification}", + howpublished="RFC 5348 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5348", + pages="1--58", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5348.txt", + key="RFC 5348", + abstract={This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]}, + keywords="tcp-friendly rate control, congestion control", + doi="10.17487/RFC5348", + } + +@misc{rfc5349, + author="L. Zhu and K. Jaganathan and K. Lauter", + title="{Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)}", + howpublished="RFC 5349 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5349", + pages="1--10", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5349.txt", + key="RFC 5349", + abstract={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.}, + keywords="ecdh, elliptic curve diffie-hellman", + doi="10.17487/RFC5349", + } + +@misc{rfc5350, + author="J. Manner and A. McDonald", + title="{IANA Considerations for the IPv4 and IPv6 Router Alert Options}", + howpublished="RFC 5350 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5350", + pages="1--8", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5350.txt", + key="RFC 5350", + abstract={This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5350", + } + +@misc{rfc5351, + author="P. Lei and L. Ong and M. Tuexen and T. Dreibholz", + title="{An Overview of Reliable Server Pooling Protocols}", + howpublished="RFC 5351 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5351", + pages="1--15", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5351.txt", + key="RFC 5351", + abstract={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.}, + keywords="rserpool", + doi="10.17487/RFC5351", + } + +@misc{rfc5352, + author="R. Stewart and Q. Xie and M. Stillman and M. Tuexen", + title="{Aggregate Server Access Protocol (ASAP)}", + howpublished="RFC 5352 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5352", + pages="1--53", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5352.txt", + key="RFC 5352", + abstract={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. 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. 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 tran sport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol. 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.}, + keywords="rserpool, enrp, endpoint handlespace redundancy protocol", + doi="10.17487/RFC5352", + } + +@misc{rfc5353, + author="Q. Xie and R. Stewart and M. Stillman and M. Tuexen and A. Silverton", + title="{Endpoint Handlespace Redundancy Protocol (ENRP)}", + howpublished="RFC 5353 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5353", + pages="1--39", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5353.txt", + key="RFC 5353", + abstract={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.}, + keywords="rserpool, asap, aggregate server access protocol, fault-tolerant registry", + doi="10.17487/RFC5353", + } + +@misc{rfc5354, + author="R. Stewart and Q. Xie and M. Stillman and M. Tuexen", + title="{Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters}", + howpublished="RFC 5354 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5354", + pages="1--23", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5354.txt", + key="RFC 5354", + abstract={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.}, + keywords="rserpool", + doi="10.17487/RFC5354", + } + +@misc{rfc5355, + author="M. {Stillman (Ed.)} and R. Gopal and E. Guttman and S. Sengodan and M. Holdrege", + title="{Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats}", + howpublished="RFC 5355 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5355", + pages="1--19", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5355.txt", + key="RFC 5355", + abstract={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.}, + doi="10.17487/RFC5355", + } + +@misc{rfc5356, + author="T. Dreibholz and M. Tuexen", + title="{Reliable Server Pooling Policies}", + howpublished="RFC 5356 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5356", + pages="1--16", + year=2008, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5356.txt", + key="RFC 5356", + abstract={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.}, + keywords="rserpool, enrp, endpoint handlespace redundancy protocol", + doi="10.17487/RFC5356", + } + +@misc{rfc5357, + author="K. Hedayat and R. Krzanowski and A. Morton and K. Yum and J. Babiarz", + title="{A Two-Way Active Measurement Protocol (TWAMP)}", + howpublished="RFC 5357 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5357", + pages="1--26", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5618, 5938, 6038, 7717, 7750", +url="https://www.rfc-editor.org/rfc/rfc5357.txt", + key="RFC 5357", + abstract={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]}, + keywords="two-way measaurement, round-trip measurement", + doi="10.17487/RFC5357", + } + +@misc{rfc5358, + author="J. Damas and F. Neves", + title="{Preventing Use of Recursive Nameservers in Reflector Attacks}", + howpublished="RFC 5358 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5358", + pages="1--7", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5358.txt", + key="RFC 5358", + abstract={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.}, + keywords="denial of service, dos", + doi="10.17487/RFC5358", + } + +@misc{rfc5359, + author="A. {Johnston (Ed.)} and R. Sparks and C. Cunningham and S. Donovan and K. Summers", + title="{Session Initiation Protocol Service Examples}", + howpublished="RFC 5359 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5359", + pages="1--170", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5359.txt", + key="RFC 5359", + abstract={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.}, + keywords="sip, pbx, centrex, features, hold, transfer, forwarding, screening, park, pickup, redial, click, call flows", + doi="10.17487/RFC5359", + } + +@misc{rfc5360, + author="J. Rosenberg and G. {Camarillo (Ed.)} and D. Willis", + title="{A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5360 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5360", + pages="1--31", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8217", +url="https://www.rfc-editor.org/rfc/rfc5360.txt", + key="RFC 5360", + abstract={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]}, + doi="10.17487/RFC5360", + } + +@misc{rfc5361, + author="G. Camarillo", + title="{A Document Format for Requesting Consent}", + howpublished="RFC 5361 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5361", + pages="1--14", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5361.txt", + key="RFC 5361", + abstract={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]}, + keywords="xml, extensible markup language, premission document", + doi="10.17487/RFC5361", + } + +@misc{rfc5362, + author="G. Camarillo", + title="{The Session Initiation Protocol (SIP) Pending Additions Event Package}", + howpublished="RFC 5362 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5362", + pages="1--16", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5362.txt", + key="RFC 5362", + abstract={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]}, + keywords="consent-related, resource list", + doi="10.17487/RFC5362", + } + +@misc{rfc5363, + author="G. Camarillo and A.B. Roach", + title="{Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services}", + howpublished="RFC 5363 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5363", + pages="1--10", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5363.txt", + key="RFC 5363", + abstract={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]}, + keywords="", + doi="10.17487/RFC5363", + } + +@misc{rfc5364, + author="M. Garcia-Martin and G. Camarillo", + title="{Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists}", + howpublished="RFC 5364 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5364", + pages="1--17", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5364.txt", + key="RFC 5364", + abstract={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]}, + keywords="XML, copy, control, resource, list", + doi="10.17487/RFC5364", + } + +@misc{rfc5365, + author="M. Garcia-Martin and G. Camarillo", + title="{Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5365 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5365", + pages="1--18", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5365.txt", + key="RFC 5365", + abstract={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]}, + keywords="user agent client, uac, sip message request, uniform resource identifier list, message uri list", + doi="10.17487/RFC5365", + } + +@misc{rfc5366, + author="G. Camarillo and A. Johnston", + title="{Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5366 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5366", + pages="1--13", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5366.txt", + key="RFC 5366", + abstract={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]}, + keywords="sip uri list, invite-contatined uri", + doi="10.17487/RFC5366", + } + +@misc{rfc5367, + author="G. Camarillo and A.B. Roach and O. Levin", + title="{Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5367 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5367", + pages="1--9", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5367.txt", + key="RFC 5367", + abstract={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]}, + keywords="subscribe request, resrouce list", + doi="10.17487/RFC5367", + } + +@misc{rfc5368, + author="G. Camarillo and A. Niemi and M. Isomaki and M. Garcia-Martin and H. Khartabil", + title="{Referring to Multiple Resources in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5368 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5368", + pages="1--13", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8262", +url="https://www.rfc-editor.org/rfc/rfc5368.txt", + key="RFC 5368", + abstract={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]}, + keywords="sip refer, refer-to, multipler-refer", + doi="10.17487/RFC5368", + } + +@misc{rfc5369, + author="G. Camarillo", + title="{Framework for Transcoding with the Session Initiation Protocol (SIP)}", + howpublished="RFC 5369 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5369", + pages="1--10", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5369.txt", + key="RFC 5369", + abstract={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.}, + keywords="transcoding services, conference bridge model, third-party call control model, deaf, hard of hearing, speech-impaired", + doi="10.17487/RFC5369", + } + +@misc{rfc5370, + author="G. Camarillo", + title="{The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model}", + howpublished="RFC 5370 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5370", + pages="1--11", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5370.txt", + key="RFC 5370", + abstract={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]}, + keywords="transcoding service, deaf, hard of hearing, speech-impaired", + doi="10.17487/RFC5370", + } + +@misc{rfc5371, + author="S. Futemma and E. Itakura and A. Leung", + title="{RTP Payload Format for JPEG 2000 Video Streams}", + howpublished="RFC 5371 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5371", + pages="1--31", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5371.txt", + key="RFC 5371", + abstract={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]}, + keywords="JPEG 2000 video, RTP, Real-time Transport Protocol, main header, tile number, Sony Corporation", + doi="10.17487/RFC5371", + } + +@misc{rfc5372, + author="A. Leung and S. Futemma and E. Itakura", + title="{Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery}", + howpublished="RFC 5372 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5372", + pages="1--26", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5372.txt", + key="RFC 5372", + abstract={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. 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]}, + keywords="Real-time Transport Protocol, main header compensation, priority field, priority mapping table, packet-number-based ordering, progression-based ordering, layer-based ordering, resolution-based ordering, component-based ordering, Sony Corporation", + doi="10.17487/RFC5372", + } + +@misc{rfc5373, + author="D. {Willis (Ed.)} and A. Allen", + title="{Requesting Answering Modes for the Session Initiation Protocol (SIP)}", + howpublished="RFC 5373 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5373", + pages="1--24", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5373.txt", + key="RFC 5373", + abstract={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]}, + keywords="PoC, PTT, auto, automatic, manual, answer, loopback, diagnostic, answer-mode, priv-answer-mode", + doi="10.17487/RFC5373", + } + +@misc{rfc5374, + author="B. Weis and G. Gross and D. Ignjatic", + title="{Multicast Extensions to the Security Architecture for the Internet Protocol}", + howpublished="RFC 5374 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5374", + pages="1--38", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5374.txt", + key="RFC 5374", + abstract={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]}, + keywords="ip, ipsec, ip multicast packets", + doi="10.17487/RFC5374", + } + +@misc{rfc5375, + author="G. Van de Velde and C. Popoviciu and T. Chown and O. Bonness and C. Hahn", + title="{IPv6 Unicast Address Assignment Considerations}", + howpublished="RFC 5375 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5375", + pages="1--35", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5375.txt", + key="RFC 5375", + abstract={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.}, + keywords="internet protocol version 6, address architecture", + doi="10.17487/RFC5375", + } + +@misc{rfc5376, + author="N. Bitar and R. Zhang and K. Kumaki", + title="{Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)}", + howpublished="RFC 5376 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5376", + pages="1--14", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5376.txt", + key="RFC 5376", + abstract={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. 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.}, + keywords="PCE, PCECP, inter-AS PCE, inter-provider PCE, inter-AS MPLS-TE, inter-provider MPLS-TE, inter-AS PCECP, inter-provider PCECP, GMPLS path computation, MPLS-TE path computation, path computation element, path computation communication protocol, path computing element, Interas, Interas TE", + doi="10.17487/RFC5376", + } + +@misc{rfc5377, + author="J. {Halpern (Ed.)}", + title="{Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents}", + howpublished="RFC 5377 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5377", + pages="1--8", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5377.txt", + key="RFC 5377", + abstract={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.}, + keywords="contributors, ietf contributions, outbound rights", + doi="10.17487/RFC5377", + } + +@misc{rfc5378, + author="S. {Bradner (Ed.)} and J. {Contreras (Ed.)}", + title="{Rights Contributors Provide to the IETF Trust}", + howpublished="RFC 5378 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5378", + pages="1--16", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5378.txt", + key="RFC 5378", + abstract={The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo 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.}, + keywords="intellectual property rights, copyright, ipr", + doi="10.17487/RFC5378", + } + +@misc{rfc5379, + author="M. Munakata and S. Schubert and T. Ohba", + title="{Guidelines for Using the Privacy Mechanism for SIP}", + howpublished="RFC 5379 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5379", + pages="1--23", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5379.txt", + key="RFC 5379", + abstract={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.}, + keywords="SIP, Privacy, priv-value, guideline", + doi="10.17487/RFC5379", + } + +@misc{rfc5380, + author="H. Soliman and C. Castelluccia and K. ElMalki and L. Bellier", + title="{Hierarchical Mobile IPv6 (HMIPv6) Mobility Management}", + howpublished="RFC 5380 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5380", + pages="1--26", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5380.txt", + key="RFC 5380", + abstract={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]}, + keywords="mobile ipv6, ipv6 neighbor discovery, map, mobility anchor point", + doi="10.17487/RFC5380", + } + +@misc{rfc5381, + author="T. Iijima and Y. Atarashi and H. Kimura and M. Kitani and H. Okita", + title="{Experience of Implementing NETCONF over SOAP}", + howpublished="RFC 5381 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5381", + pages="1--22", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5381.txt", + key="RFC 5381", + abstract={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.}, + keywords="simple object access protocol, network configuration protocol, mns, network management system", + doi="10.17487/RFC5381", + } + +@misc{rfc5382, + author="S. {Guha (Ed.)} and K. Biswas and B. Ford and S. Sivakumar and P. Srisuresh", + title="{NAT Behavioral Requirements for TCP}", + howpublished="RFC 5382 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5382", + pages="1--31", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7857", +url="https://www.rfc-editor.org/rfc/rfc5382.txt", + key="RFC 5382", + abstract={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.}, + keywords="network address translation", + doi="10.17487/RFC5382", + } + +@misc{rfc5383, + author="R. Gellens", + title="{Deployment Considerations for Lemonade-Compliant Mobile Email}", + howpublished="RFC 5383 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5383", + pages="1--12", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5383.txt", + key="RFC 5383", + abstract={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.}, + keywords="", + doi="10.17487/RFC5383", + } + +@misc{rfc5384, + author="A. Boers and I. Wijnands and E. Rosen", + title="{The Protocol Independent Multicast (PIM) Join Attribute Format}", + howpublished="RFC 5384 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5384", + pages="1--10", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7887", +url="https://www.rfc-editor.org/rfc/rfc5384.txt", + key="RFC 5384", + abstract={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]}, + keywords="pim-sm, multicast distribution tree, pim join attribute, attr\_type", + doi="10.17487/RFC5384", + } + +@misc{rfc5385, + author="J. Touch", + title="{Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs}", + howpublished="RFC 5385 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5385", + pages="1--20", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5385.txt", + key="RFC 5385", + abstract={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. 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.}, + keywords="writing I-Ds, writing RFCs, authoring, tools, document preparation", + doi="10.17487/RFC5385", + } + +@misc{rfc5386, + author="N. Williams and M. Richardson", + title="{Better-Than-Nothing Security: An Unauthenticated Mode of IPsec}", + howpublished="RFC 5386 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5386", + pages="1--11", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5386.txt", + key="RFC 5386", + abstract={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]}, + keywords="internet protocol security, ikev1, ikev2, sas, esp, ah, pad, spd, btns, unauthenticated ipsec", + doi="10.17487/RFC5386", + } + +@misc{rfc5387, + author="J. Touch and D. Black and Y. Wang", + title="{Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)}", + howpublished="RFC 5387 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5387", + pages="1--28", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5387.txt", + key="RFC 5387", + abstract={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. 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 cal led 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.}, + keywords="ipsec, stand-alone btns, sab, channel-bound btns, cbb", + doi="10.17487/RFC5387", + } + +@misc{rfc5388, + author="S. Niccolini and S. Tartarelli and J. Quittek and T. Dietz and M. Swany", + title="{Information Model and XML Data Model for Traceroute Measurements}", + howpublished="RFC 5388 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5388", + pages="1--75", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5388.txt", + key="RFC 5388", + abstract={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]}, + keywords="extensible markup language, DISMAN-TRACEROUTE-MIB", + doi="10.17487/RFC5388", + } + +@misc{rfc5389, + author="J. Rosenberg and R. Mahy and P. Matthews and D. Wing", + title="{Session Traversal Utilities for NAT (STUN)}", + howpublished="RFC 5389 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5389", + pages="1--51", + year=2008, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7350", +url="https://www.rfc-editor.org/rfc/rfc5389.txt", + key="RFC 5389", + abstract={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. 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. This document obsoletes RFC 3489. [STANDARDS-TRACK]}, + keywords="SIPs, NAT, STUN, Traversal, ICE, firewall, TURN, VOIP", + doi="10.17487/RFC5389", + } + +@misc{rfc5390, + author="J. Rosenberg", + title="{Requirements for Management of Overload in the Session Initiation Protocol}", + howpublished="RFC 5390 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5390", + pages="1--14", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5390.txt", + key="RFC 5390", + abstract={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.}, + keywords="sip, overload handling, 503 response", + doi="10.17487/RFC5390", + } + +@misc{rfc5391, + author="A. Sollaud", + title="{RTP Payload Format for ITU-T Recommendation G.711.1}", + howpublished="RFC 5391 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5391", + pages="1--14", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5391.txt", + key="RFC 5391", + abstract={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]}, + keywords="real-time transport protocol, itu telecommunication standardization sector, audio coded, pcmu-wb, pcma-wb", + doi="10.17487/RFC5391", + } + +@misc{rfc5392, + author="M. Chen and R. Zhang and X. Duan", + title="{OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering}", + howpublished="RFC 5392 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5392", + pages="1--17", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5392.txt", + key="RFC 5392", + abstract={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. No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]}, + keywords="multiprotocol label switching, generalized mpls, gmpls-te, mpls-te, isis-te, open shortest path first, ospf-te", + doi="10.17487/RFC5392", + } + +@misc{rfc5393, + author="R. {Sparks (Ed.)} and S. Lawrence and A. Hawrylyshen and B. Campen", + title="{Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies}", + howpublished="RFC 5393 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5393", + pages="1--20", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5393.txt", + key="RFC 5393", + abstract={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. 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]}, + keywords="SIP, application-layer, application, layer, multimedia, multicast, unicast", + doi="10.17487/RFC5393", + } + +@misc{rfc5394, + author="I. Bryskin and D. Papadimitriou and L. Berger and J. Ash", + title="{Policy-Enabled Path Computation Framework}", + howpublished="RFC 5394 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5394", + pages="1--36", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5394.txt", + key="RFC 5394", + abstract={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.}, + keywords="PCE, pce policy", + doi="10.17487/RFC5394", + } + +@misc{rfc5395, + author="D. {Eastlake 3rd}", + title="{Domain Name System (DNS) IANA Considerations}", + howpublished="RFC 5395 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5395", + pages="1--17", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6195", +url="https://www.rfc-editor.org/rfc/rfc5395.txt", + key="RFC 5395", + abstract={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.}, + keywords="RRTYPE, RCODE, AFSDB", + doi="10.17487/RFC5395", + } + +@misc{rfc5396, + author="G. Huston and G. Michaelson", + title="{Textual Representation of Autonomous System (AS) Numbers}", + howpublished="RFC 5396 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5396", + pages="1--3", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5396.txt", + key="RFC 5396", + abstract={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]}, + keywords="decimal value", + doi="10.17487/RFC5396", + } + +@misc{rfc5397, + author="W. Sanchez and C. Daboo", + title="{WebDAV Current Principal Extension}", + howpublished="RFC 5397 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5397", + pages="1--5", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5397.txt", + key="RFC 5397", + abstract={This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. [STANDARDS-TRACK]}, + keywords="http, webdav, access control, acl, authentication", + doi="10.17487/RFC5397", + } + +@misc{rfc5398, + author="G. Huston", + title="{Autonomous System (AS) Number Reservation for Documentation Use}", + howpublished="RFC 5398 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5398", + pages="1--4", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5398.txt", + key="RFC 5398", + abstract={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.}, + keywords="autonomous system numbers, asn", + doi="10.17487/RFC5398", + } + +@misc{rfc5401, + author="B. Adamson and C. Bormann and M. Handley and J. Macker", + title="{Multicast Negative-Acknowledgment (NACK) Building Blocks}", + howpublished="RFC 5401 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5401", + pages="1--42", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5401.txt", + key="RFC 5401", + abstract={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]}, + keywords="", + doi="10.17487/RFC5401", + } + +@misc{rfc5402, + author="T. {Harding (Ed.)}", + title="{Compressed Data within an Internet Electronic Data Interchange (EDI) Message}", + howpublished="RFC 5402 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5402", + pages="1--7", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5402.txt", + key="RFC 5402", + abstract={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.}, + keywords="internet edi", + doi="10.17487/RFC5402", + } + +@misc{rfc5403, + author="M. Eisler", + title="{RPCSEC\_GSS Version 2}", + howpublished="RFC 5403 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5403", + pages="1--14", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7861", +url="https://www.rfc-editor.org/rfc/rfc5403.txt", + key="RFC 5403", + abstract={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]}, + keywords="Kerberos, ONC, RPC, security, authentication, integrity, GSS, GSS-API, privacy, confidentiality, encryption, MIC, NFS, credential, verifier, mechanism, context", + doi="10.17487/RFC5403", + } + +@misc{rfc5404, + author="M. Westerlund and I. Johansson", + title="{RTP Payload Format for G.719}", + howpublished="RFC 5404 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5404", + pages="1--27", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5404.txt", + key="RFC 5404", + abstract={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]}, + keywords="ITU-T, g.719 full-band codec", + doi="10.17487/RFC5404", + } + +@misc{rfc5405, + author="L. Eggert and G. Fairhurst", + title="{Unicast UDP Usage Guidelines for Application Designers}", + howpublished="RFC 5405 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5405", + pages="1--27", + year=2008, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8085", +url="https://www.rfc-editor.org/rfc/rfc5405.txt", + key="RFC 5405", + abstract={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.}, + keywords="user datagram protocol, congestion control", + doi="10.17487/RFC5405", + } + +@misc{rfc5406, + author="S. Bellovin", + title="{Guidelines for Specifying the Use of IPsec Version 2}", + howpublished="RFC 5406 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5406", + pages="1--13", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5406.txt", + key="RFC 5406", + abstract={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.}, + keywords="internet security, security considerations", + doi="10.17487/RFC5406", + } + +@misc{rfc5407, + author="M. Hasebe and J. Koshiko and Y. Suzuki and T. Yoshikawa and P. Kyzivat", + title="{Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5407 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5407", + pages="1--60", + year=2008, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5407.txt", + key="RFC 5407", + abstract={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.}, + keywords="sip user agents, sip ua, sip proxy servers", + doi="10.17487/RFC5407", + } + +@misc{rfc5408, + author="G. Appenzeller and L. Martin and M. Schertler", + title="{Identity-Based Encryption Architecture and Supporting Data Structures}", + howpublished="RFC 5408 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5408", + pages="1--30", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5408.txt", + key="RFC 5408", + abstract={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.}, + keywords="public key, public-key encryption technology", + doi="10.17487/RFC5408", + } + +@misc{rfc5409, + author="L. Martin and M. Schertler", + title="{Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 5409 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5409", + pages="1--13", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5409.txt", + key="RFC 5409", + abstract={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.}, + keywords="bf, bbq, content-encryption keys", + doi="10.17487/RFC5409", + } + +@misc{rfc5410, + author="A. {Jerichow (Ed.)} and L. Piron", + title="{Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0}", + howpublished="RFC 5410 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5410", + pages="1--7", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6309", +url="https://www.rfc-editor.org/rfc/rfc5410.txt", + key="RFC 5410", + keywords="MIKEY Extension, IANA registration, OMA BCAST", + doi="10.17487/RFC5410", + } + +@misc{rfc5411, + author="J. Rosenberg", + title="{A Hitchhiker's Guide to the Session Initiation Protocol (SIP)}", + howpublished="RFC 5411 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5411", + pages="1--39", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5411.txt", + key="RFC 5411", + abstract={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.}, + keywords="42, don't panic, sip overview,", + doi="10.17487/RFC5411", + } + +@misc{rfc5412, + author="P. Calhoun and R. Suri and N. Cam-Winget and M. Williams and S. Hares and B. O'Hara and S. Kelly", + title="{Lightweight Access Point Protocol}", + howpublished="RFC 5412 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5412", + pages="1--125", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5412.txt", + key="RFC 5412", + abstract={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. 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 docu ment 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.}, + keywords="lwapp, capwap", + doi="10.17487/RFC5412", + } + +@misc{rfc5413, + author="P. Narasimhan and D. Harkins and S. Ponnuswamy", + title="{SLAPP: Secure Light Access Point Protocol}", + howpublished="RFC 5413 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5413", + pages="1--75", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5413.txt", + key="RFC 5413", + abstract={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. 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. Even though the text in this document is written to spec ifically 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.}, + keywords="capwap", + doi="10.17487/RFC5413", + } + +@misc{rfc5414, + author="S. Iino and S. Govindan and M. Sugiura and H. Cheng", + title="{Wireless LAN Control Protocol (WiCoP)}", + howpublished="RFC 5414 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5414", + pages="1--54", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 5415", +url="https://www.rfc-editor.org/rfc/rfc5414.txt", + key="RFC 5414", + abstract={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. 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.}, + keywords="wlan, wireless local area network, twp, wireless termination points, capwap, control and provisioning of wireless access points", + doi="10.17487/RFC5414", + } + +@misc{rfc5415, + author="P. {Calhoun (Ed.)} and M. {Montemurro (Ed.)} and D. {Stanley (Ed.)}", + title="{Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification}", + howpublished="RFC 5415 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5415", + pages="1--155", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5415.txt", + key="RFC 5415", + abstract={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]}, + keywords="LWAPP, CAPWAP, 802.11, IEEE, Wireless LAN, WiFi, Access Point, Access Controller, Wireless Termination Point", + doi="10.17487/RFC5415", + } + +@misc{rfc5416, + author="P. {Calhoun (Ed.)} and M. {Montemurro (Ed.)} and D. {Stanley (Ed.)}", + title="{Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11}", + howpublished="RFC 5416 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5416", + pages="1--76", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5416.txt", + key="RFC 5416", + abstract={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. 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]}, + keywords="Operations and Management, LWAPP, CAPWAP, 802.11, IEEE, Wireless LAN, WiFi, Access Point, Access Controller, Wireless Termination Point", + doi="10.17487/RFC5416", + } + +@misc{rfc5417, + author="P. Calhoun", + title="{Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option}", + howpublished="RFC 5417 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5417", + pages="1--6", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5417.txt", + key="RFC 5417", + abstract={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]}, + keywords="CAPWAP, 802.11, IEEE, Wireless LAN, WiFi, Access Point, Access Controller, Wireless Termination Point", + doi="10.17487/RFC5417", + } + +@misc{rfc5418, + author="S. Kelly and T. Clancy", + title="{Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments}", + howpublished="RFC 5418 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5418", + pages="1--34", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5418.txt", + key="RFC 5418", + abstract={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.}, + keywords="WLAN, security", + doi="10.17487/RFC5418", + } + +@misc{rfc5419, + author="B. Patil and G. Dommety", + title="{Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)}", + howpublished="RFC 5419 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5419", + pages="1--19", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5419.txt", + key="RFC 5419", + abstract={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.}, + keywords="authentication signaling message, mn, ha", + doi="10.17487/RFC5419", + } + +@misc{rfc5420, + author="A. {Farrel (Ed.)} and D. Papadimitriou and JP. Vasseur and A. Ayyangarps", + title="{Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)}", + howpublished="RFC 5420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5420", + pages="1--22", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6510", +url="https://www.rfc-editor.org/rfc/rfc5420.txt", + key="RFC 5420", + abstract={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. 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. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC L SPs. 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]}, + keywords="multiprotocol label switching, label switched paths, SESSION\_ATTRIBUTE", + doi="10.17487/RFC5420", + } + +@misc{rfc5421, + author="N. Cam-Winget and H. Zhou", + title="{Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)}", + howpublished="RFC 5421 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5421", + pages="1--10", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5421.txt", + key="RFC 5421", + abstract={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.}, + keywords="generic token card, eap-gtc", + doi="10.17487/RFC5421", + } + +@misc{rfc5422, + author="N. Cam-Winget and D. McGrew and J. Salowey and H. Zhou", + title="{Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)}", + howpublished="RFC 5422 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5422", + pages="1--39", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5422.txt", + key="RFC 5422", + abstract={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.}, + doi="10.17487/RFC5422", + } + +@misc{rfc5423, + author="R. Gellens and C. Newman", + title="{Internet Message Store Events}", + howpublished="RFC 5423 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5423", + pages="1--17", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5423.txt", + key="RFC 5423", + abstract={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. 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]}, + keywords="imap", + doi="10.17487/RFC5423", + } + +@misc{rfc5424, + author="R. Gerhards", + title="{The Syslog Protocol}", + howpublished="RFC 5424 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5424", + pages="1--38", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5424.txt", + key="RFC 5424", + abstract={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. 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 wri tten once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]}, + keywords="event notification message, syslog message, berkeley, software, distribution, transmission, messages", + doi="10.17487/RFC5424", + } + +@misc{rfc5425, + author="F. {Miao (Ed.)} and Y. {Ma (Ed.)} and J. {Salowey (Ed.)}", + title="{Transport Layer Security (TLS) Transport Mapping for Syslog}", + howpublished="RFC 5425 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5425", + pages="1--13", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5425.txt", + key="RFC 5425", + abstract={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. [STANDARDS-TRACK]}, + keywords="syslog message, syslog security", + doi="10.17487/RFC5425", + } + +@misc{rfc5426, + author="A. Okmianski", + title="{Transmission of Syslog Messages over UDP}", + howpublished="RFC 5426 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5426", + pages="1--9", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5426.txt", + key="RFC 5426", + abstract={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]}, + keywords="udp, User Datagram Protocol", + doi="10.17487/RFC5426", + } + +@misc{rfc5427, + author="G. Keeni", + title="{Textual Conventions for Syslog Management}", + howpublished="RFC 5427 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5427", + pages="1--8", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5427.txt", + key="RFC 5427", + abstract={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]}, + keywords="syslog facility, syslog severity, MIB, textual-convention", + doi="10.17487/RFC5427", + } + +@misc{rfc5428, + author="S. Channabasappa and W. De Ketelaere and E. Nechamkin", + title="{Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices}", + howpublished="RFC 5428 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5428", + pages="1--37", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5428.txt", + key="RFC 5428", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]}, + keywords="snmp, simple network management protocol, multimedia terminal adapter, PKTC-IETF-EVENT-MIB", + doi="10.17487/RFC5428", + } + +@misc{rfc5429, + author="A. {Stone (Ed.)}", + title="{Sieve Email Filtering: Reject and Extended Reject Extensions}", + howpublished="RFC 5429 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5429", + pages="1--14", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5429.txt", + key="RFC 5429", + abstract={This memo updates the definition of the Sieve mail filtering language ``reject'' extension, originally defined in RFC 3028. 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. 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. 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]}, + keywords="sieve, refuse, reject, ereject, joe-job, smtp, lmtp, spam", + doi="10.17487/RFC5429", + } + +@misc{rfc5430, + author="M. Salter and E. Rescorla and R. Housley", + title="{Suite B Profile for Transport Layer Security (TLS)}", + howpublished="RFC 5430 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5430", + pages="1--12", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6460", +url="https://www.rfc-editor.org/rfc/rfc5430.txt", + key="RFC 5430", + abstract={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.}, + keywords="nsa suite b cryptography", + doi="10.17487/RFC5430", + } + +@misc{rfc5431, + author="D. Sun", + title="{Diameter ITU-T Rw Policy Enforcement Interface Application}", + howpublished="RFC 5431 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5431", + pages="1--5", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5431.txt", + key="RFC 5431", + abstract={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.}, + keywords="diameter command code, itu-t, ITU-T Rw, Policy-Install-Request, pir, Policy-Install-Answer, pia", + doi="10.17487/RFC5431", + } + +@misc{rfc5432, + author="J. Polk and S. Dhesikan and G. Camarillo", + title="{Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)}", + howpublished="RFC 5432 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5432", + pages="1--9", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5432.txt", + key="RFC 5432", + abstract={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]}, + keywords="offer/answer, media stream", + doi="10.17487/RFC5432", + } + +@misc{rfc5433, + author="T. Clancy and H. Tschofenig", + title="{Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method}", + howpublished="RFC 5433 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5433", + pages="1--38", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5433.txt", + key="RFC 5433", + abstract={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]}, + keywords="EAP, EAP-GPSK, pre-shared key", + doi="10.17487/RFC5433", + } + +@misc{rfc5434, + author="T. Narten", + title="{Considerations for Having a Successful Birds-of-a-Feather (BOF) Session}", + howpublished="RFC 5434 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5434", + pages="1--13", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5434.txt", + key="RFC 5434", + abstract={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]}, + keywords="ietf bof, working group", + doi="10.17487/RFC5434", + } + +@misc{rfc5435, + author="A. {Melnikov (Ed.)} and B. {Leiba (Ed.)} and W. Segmuller and T. Martin", + title="{Sieve Email Filtering: Extension for Notifications}", + howpublished="RFC 5435 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5435", + pages="1--17", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5435.txt", + key="RFC 5435", + abstract={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]}, + keywords="", + doi="10.17487/RFC5435", + } + +@misc{rfc5436, + author="B. Leiba and M. Haardt", + title="{Sieve Notification Mechanism: mailto}", + howpublished="RFC 5436 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5436", + pages="1--12", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5436.txt", + key="RFC 5436", + abstract={This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK]}, + keywords="eletctronic mail notification", + doi="10.17487/RFC5436", + } + +@misc{rfc5437, + author="P. Saint-Andre and A. Melnikov", + title="{Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 5437 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5437", + pages="1--14", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5437.txt", + key="RFC 5437", + abstract={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]}, + keywords="jabber", + doi="10.17487/RFC5437", + } + +@misc{rfc5438, + author="E. Burger and H. Khartabil", + title="{Instant Message Disposition Notification (IMDN)}", + howpublished="RFC 5438 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5438", + pages="1--38", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5438.txt", + key="RFC 5438", + abstract={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. 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. This document also describes how SIP entities behave using this extension. [STANDARDS-TRACK]}, + keywords="im, instant messaging, cpim, common presence and instant messaging", + doi="10.17487/RFC5438", + } + +@misc{rfc5439, + author="S. Yasukawa and A. Farrel and O. Komolafe", + title="{An Analysis of Scaling Issues in MPLS-TE Core Networks}", + howpublished="RFC 5439 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5439", + pages="1--45", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5439.txt", + key="RFC 5439", + abstract={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. 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. 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.}, + keywords="multiprotocol label switching, traffic engineered, scaling concerns, lsp, label switch path, point-to-point mpls-te lsps", + doi="10.17487/RFC5439", + } + +@misc{rfc5440, + author="JP. {Vasseur (Ed.)} and JL. Le {Roux (Ed.)}", + title="{Path Computation Element (PCE) Communication Protocol (PCEP)}", + howpublished="RFC 5440 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5440", + pages="1--87", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7896, 8253, 8356", +url="https://www.rfc-editor.org/rfc/rfc5440.txt", + key="RFC 5440", + abstract={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]}, + keywords="MPLS, GMPLS, Traffic Engineering, Label Switched Path", + doi="10.17487/RFC5440", + } + +@misc{rfc5441, + author="JP. {Vasseur (Ed.)} and R. Zhang and N. Bitar and JL. Le Roux", + title="{A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths}", + howpublished="RFC 5441 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5441", + pages="1--18", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5441.txt", + key="RFC 5441", + abstract={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]}, + keywords="te lsp, path computation element", + doi="10.17487/RFC5441", + } + +@misc{rfc5442, + author="E. Burger and G. Parsons", + title="{LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail}", + howpublished="RFC 5442 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5442", + pages="1--15", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5442.txt", + key="RFC 5442", + abstract={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.}, + keywords="enhancements to internet email to supportt diverse service environments, Phone", + doi="10.17487/RFC5442", + } + +@misc{rfc5443, + author="M. Jork and A. Atlas and L. Fang", + title="{LDP IGP Synchronization}", + howpublished="RFC 5443 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5443", + pages="1--7", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6138", +url="https://www.rfc-editor.org/rfc/rfc5443.txt", + key="RFC 5443", + abstract={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.}, + keywords="label distribution protocol, interior gateway protocol", + doi="10.17487/RFC5443", + } + +@misc{rfc5444, + author="T. Clausen and C. Dearlove and J. Dean and C. Adjih", + title="{Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format}", + howpublished="RFC 5444 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5444", + pages="1--60", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7631, 8245", +url="https://www.rfc-editor.org/rfc/rfc5444.txt", + key="RFC 5444", + abstract={This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. [STANDARDS-TRACK]}, + keywords="routing, TLV, address", + doi="10.17487/RFC5444", + } + +@misc{rfc5445, + author="M. Watson", + title="{Basic Forward Error Correction (FEC) Schemes}", + howpublished="RFC 5445 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5445", + pages="1--19", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5445.txt", + key="RFC 5445", + abstract={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]}, + keywords="content, stream, delivery, multicast, internet protocol", + doi="10.17487/RFC5445", + } + +@misc{rfc5446, + author="J. Korhonen and U. Nilsson", + title="{Service Selection for Mobile IPv4}", + howpublished="RFC 5446 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5446", + pages="1--9", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5446.txt", + key="RFC 5446", + abstract={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.}, + keywords="internet protocol version 4, host name agent, mobility service subscription", + doi="10.17487/RFC5446", + } + +@misc{rfc5447, + author="J. {Korhonen (Ed.)} and J. Bournelle and H. Tschofenig and C. Perkins and K. Chowdhury", + title="{Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction}", + howpublished="RFC 5447 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5447", + pages="1--17", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5447.txt", + key="RFC 5447", + abstract={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]}, + keywords="Diameter, Mobile IPv6, Integrated Scenario", + doi="10.17487/RFC5447", + } + +@misc{rfc5448, + author="J. Arkko and V. Lehtovirta and P. Eronen", + title="{Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')}", + howpublished="RFC 5448 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5448", + pages="1--29", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5448.txt", + key="RFC 5448", + abstract={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. This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.}, + keywords="EAP, AKA, AKA', 3GPP", + doi="10.17487/RFC5448", + } + +@misc{rfc5449, + author="E. Baccelli and P. Jacquet and D. Nguyen and T. Clausen", + title="{OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks}", + howpublished="RFC 5449 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5449", + pages="1--31", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5449.txt", + key="RFC 5449", + abstract={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.}, + keywords="open shortest path first, interface type, mobile ad hoc", + doi="10.17487/RFC5449", + } + +@misc{rfc5450, + author="D. Singer and H. Desineni", + title="{Transmission Time Offsets in RTP Streams}", + howpublished="RFC 5450 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5450", + pages="1--8", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5450.txt", + key="RFC 5450", + abstract={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]}, + keywords="real-time transport, IJ, inter-arrival jitter", + doi="10.17487/RFC5450", + } + +@misc{rfc5451, + author="M. Kucherawy", + title="{Message Header Field for Indicating Message Authentication Status}", + howpublished="RFC 5451 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5451", + pages="1--43", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7001, updated by RFC 6577", +url="https://www.rfc-editor.org/rfc/rfc5451.txt", + key="RFC 5451", + abstract={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]}, + keywords="authentication-results, email authentication result", + doi="10.17487/RFC5451", + } + +@misc{rfc5452, + author="A. Hubert and R. van Mook", + title="{Measures for Making DNS More Resilient against Forged Answers}", + howpublished="RFC 5452 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5452", + pages="1--18", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5452.txt", + key="RFC 5452", + abstract={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. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. 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]}, + keywords="spoofing, source port, hardening", + doi="10.17487/RFC5452", + } + +@misc{rfc5453, + author="S. Krishnan", + title="{Reserved IPv6 Interface Identifiers}", + howpublished="RFC 5453 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5453", + pages="1--6", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5453.txt", + key="RFC 5453", + abstract={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]}, + keywords="unicast address", + doi="10.17487/RFC5453", + } + +@misc{rfc5454, + author="G. Tsirtsis and V. Park and H. Soliman", + title="{Dual-Stack Mobile IPv4}", + howpublished="RFC 5454 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5454", + pages="1--18", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5454.txt", + key="RFC 5454", + abstract={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]}, + keywords="ipv6, mipv4", + doi="10.17487/RFC5454", + } + +@misc{rfc5455, + author="S. {Sivabalan (Ed.)} and J. Parker and S. Boutros and K. Kumaki", + title="{Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol}", + howpublished="RFC 5455 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5455", + pages="1--9", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5455.txt", + key="RFC 5455", + abstract={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]}, + keywords="classtype, ds-te, diffserv-aware traffic engineering, pce", + doi="10.17487/RFC5455", + } + +@misc{rfc5456, + author="M. Spencer and B. Capouch and E. {Guy (Ed.)} and F. Miller and K. Shumard", + title="{IAX: Inter-Asterisk eXchange Version 2}", + howpublished="RFC 5456 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5456", + pages="1--101", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5456.txt", + key="RFC 5456", + abstract={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. 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 nat ure 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.}, + keywords="asterisk private branch exchange, pbx, voip, voice over internet protocol", + doi="10.17487/RFC5456", + } + +@misc{rfc5457, + author="E. {Guy (Ed.)}", + title="{IANA Considerations for IAX: Inter-Asterisk eXchange Version 2}", + howpublished="RFC 5457 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5457", + pages="1--21", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5457.txt", + key="RFC 5457", + abstract={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.}, + keywords="asterisk private branch exchange, pbx, voip, voice over internet protocol", + doi="10.17487/RFC5457", + } + +@misc{rfc5458, + author="H. Cruickshank and P. Pillai and M. Noisternig and S. Iyengar", + title="{Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol}", + howpublished="RFC 5458 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5458", + pages="1--26", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5458.txt", + key="RFC 5458", + abstract={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. 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.}, + keywords="iso 13818-1, transport stream, ts, ule stream, gse, generic stream encapsulation", + doi="10.17487/RFC5458", + } + +@misc{rfc5459, + author="A. Sollaud", + title="{G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support}", + howpublished="RFC 5459 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5459", + pages="1--7", + year=2009, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5459.txt", + key="RFC 5459", + abstract={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]}, + keywords="real-time transport protocol, rtp, itu-t, international telecommunication union, g.729.1, audio codec", + doi="10.17487/RFC5459", + } + +@misc{rfc5460, + author="M. Stapp", + title="{DHCPv6 Bulk Leasequery}", + howpublished="RFC 5460 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5460", + pages="1--18", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7653", +url="https://www.rfc-editor.org/rfc/rfc5460.txt", + key="RFC 5460", + abstract={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]}, + keywords="dynamic hos configuration protocol, ipv6, dhcpv6 bindings", + doi="10.17487/RFC5460", + } + +@misc{rfc5461, + author="F. Gont", + title="{TCP's Reaction to Soft Errors}", + howpublished="RFC 5461 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5461", + pages="1--13", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5461.txt", + key="RFC 5461", + abstract={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.}, + keywords="icmp, Internet Control Message Protocol", + doi="10.17487/RFC5461", + } + +@misc{rfc5462, + author="L. Andersson and R. Asati", + title="{Multiprotocol Label Switching (MPLS) Label Stack Entry: ``EXP'' Field Renamed to ``Traffic Class'' Field}", + howpublished="RFC 5462 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5462", + pages="1--9", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5462.txt", + key="RFC 5462", + abstract={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''. 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. 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]}, + keywords="exp, class of service, cos, tc field", + doi="10.17487/RFC5462", + } + +@misc{rfc5463, + author="N. Freed", + title="{Sieve Email Filtering: Ihave Extension}", + howpublished="RFC 5463 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5463", + pages="1--6", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5463.txt", + key="RFC 5463", + abstract={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]}, + keywords="SMTP, ESMTP", + doi="10.17487/RFC5463", + } + +@misc{rfc5464, + author="C. Daboo", + title="{The IMAP METADATA Extension}", + howpublished="RFC 5464 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5464", + pages="1--20", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5464.txt", + key="RFC 5464", + abstract={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]}, + keywords="internet message access protocol, annotation, metadata", + doi="10.17487/RFC5464", + } + +@misc{rfc5465, + author="A. Gulbrandsen and C. King and A. Melnikov", + title="{The IMAP NOTIFY Extension}", + howpublished="RFC 5465 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5465", + pages="1--22", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5465.txt", + key="RFC 5465", + abstract={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]}, + keywords="Internet Message Access Protocol", + doi="10.17487/RFC5465", + } + +@misc{rfc5466, + author="A. Melnikov and C. King", + title="{IMAP4 Extension for Named Searches (Filters)}", + howpublished="RFC 5466 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5466", + pages="1--9", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5466.txt", + key="RFC 5466", + abstract={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]}, + keywords="Internet Message Access Protocol", + doi="10.17487/RFC5466", + } + +@misc{rfc5467, + author="L. Berger and A. Takacs and D. Caviglia and D. Fedyk and J. Meuric", + title="{GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)}", + howpublished="RFC 5467 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5467", + pages="1--14", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6387", +url="https://www.rfc-editor.org/rfc/rfc5467.txt", + key="RFC 5467", + abstract={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.}, + keywords="RSVP-TE, TSPEC, ADSPEC", + doi="10.17487/RFC5467", + } + +@misc{rfc5468, + author="S. Dasgupta and J. de Oliveira and JP. Vasseur", + title="{Performance Analysis of Inter-Domain Path Computation Methodologies}", + howpublished="RFC 5468 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5468", + pages="1--10", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5468.txt", + key="RFC 5468", + abstract={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.}, + keywords="pce, path computation element, brpc, backward recursive path computation", + doi="10.17487/RFC5468", + } + +@misc{rfc5469, + author="P. {Eronen (Ed.)}", + title="{DES and IDEA Cipher Suites for Transport Layer Security (TLS)}", + howpublished="RFC 5469 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5469", + pages="1--4", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5469.txt", + key="RFC 5469", + abstract={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.}, + keywords="ciphersuite, data encryption standard, international data encryption algorithm", + doi="10.17487/RFC5469", + } + +@misc{rfc5470, + author="G. Sadasivan and N. Brownlee and B. Claise and J. Quittek", + title="{Architecture for IP Flow Information Export}", + howpublished="RFC 5470 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5470", + pages="1--31", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6183", +url="https://www.rfc-editor.org/rfc/rfc5470.txt", + key="RFC 5470", + abstract={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.}, + keywords="ipfix, ipfix device, ipfix collector", + doi="10.17487/RFC5470", + } + +@misc{rfc5471, + author="C. Schmoll and P. Aitken and B. Claise", + title="{Guidelines for IP Flow Information Export (IPFIX) Testing}", + howpublished="RFC 5471 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5471", + pages="1--32", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5471.txt", + key="RFC 5471", + abstract={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.}, + keywords="exporting process, collecting process", + doi="10.17487/RFC5471", + } + +@misc{rfc5472, + author="T. Zseby and E. Boschi and N. Brownlee and B. Claise", + title="{IP Flow Information Export (IPFIX) Applicability}", + howpublished="RFC 5472 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5472", + pages="1--31", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5472.txt", + key="RFC 5472", + abstract={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.}, + keywords="ie, information element, PSAMP, measurement, QoS monitoring, attack detection, AAA, ipfix framework", + doi="10.17487/RFC5472", + } + +@misc{rfc5473, + author="E. Boschi and L. Mark and B. Claise", + title="{Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports}", + howpublished="RFC 5473 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5473", + pages="1--27", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5473.txt", + key="RFC 5473", + abstract={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. 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.}, + doi="10.17487/RFC5473", + } + +@misc{rfc5474, + author="N. {Duffield (Ed.)} and D. Chiou and B. Claise and A. Greenberg and M. Grossglauser and J. Rexford", + title="{A Framework for Packet Selection and Reporting}", + howpublished="RFC 5474 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5474", + pages="1--38", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5474.txt", + key="RFC 5474", + abstract={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.}, + keywords="psamp, selector, collector", + doi="10.17487/RFC5474", + } + +@misc{rfc5475, + author="T. Zseby and M. Molina and N. Duffield and S. Niccolini and F. Raspall", + title="{Sampling and Filtering Techniques for IP Packet Selection}", + howpublished="RFC 5475 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5475", + pages="1--46", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5475.txt", + key="RFC 5475", + abstract={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]}, + keywords="psamp, metering process", + doi="10.17487/RFC5475", + } + +@misc{rfc5476, + author="B. {Claise (Ed.)} and A. Johnson and J. Quittek", + title="{Packet Sampling (PSAMP) Protocol Specifications}", + howpublished="RFC 5476 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5476", + pages="1--45", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5476.txt", + key="RFC 5476", + abstract={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]}, + keywords="exporting process, collecting process, ipfix, ip flow information export", + doi="10.17487/RFC5476", + } + +@misc{rfc5477, + author="T. Dietz and B. Claise and P. Aitken and F. Dressler and G. Carle", + title="{Information Model for Packet Sampling Exports}", + howpublished="RFC 5477 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5477", + pages="1--46", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5477.txt", + key="RFC 5477", + abstract={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]}, + keywords="psamp, ipfix, ip flow information export", + doi="10.17487/RFC5477", + } + +@misc{rfc5478, + author="J. Polk", + title="{IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces}", + howpublished="RFC 5478 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5478", + pages="1--6", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5478.txt", + key="RFC 5478", + abstract={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]}, + keywords="us defense information systems agency", + doi="10.17487/RFC5478", + } + +@misc{rfc5479, + author="D. {Wing (Ed.)} and S. Fries and H. Tschofenig and F. Audet", + title="{Requirements and Analysis of Media Security Management Protocols}", + howpublished="RFC 5479 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5479", + pages="1--45", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5479.txt", + key="RFC 5479", + abstract={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.}, + keywords="keying, Secure RTP, SRTP", + doi="10.17487/RFC5479", + } + +@misc{rfc5480, + author="S. Turner and D. Brown and K. Yiu and R. Housley and T. Polk", + title="{Elliptic Curve Cryptography Subject Public Key Information}", + howpublished="RFC 5480 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5480", + pages="1--20", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5480.txt", + key="RFC 5480", + abstract={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]}, + keywords="x.509, asn.1, subjectPubicKeyInfo", + doi="10.17487/RFC5480", + } + +@misc{rfc5481, + author="A. Morton and B. Claise", + title="{Packet Delay Variation Applicability Statement}", + howpublished="RFC 5481 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5481", + pages="1--39", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5481.txt", + key="RFC 5481", + abstract={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. 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.}, + keywords="active measurement, ipdv, pdv, inter-packet delay variation", + doi="10.17487/RFC5481", + } + +@misc{rfc5482, + author="L. Eggert and F. Gont", + title="{TCP User Timeout Option}", + howpublished="RFC 5482 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5482", + pages="1--14", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5482.txt", + key="RFC 5482", + abstract={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]}, + keywords="Transmission Control Protocol", + doi="10.17487/RFC5482", + } + +@misc{rfc5483, + author="L. Conroy and K. Fujiwara", + title="{ENUM Implementation Issues and Experiences}", + howpublished="RFC 5483 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5483", + pages="1--30", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5483.txt", + key="RFC 5483", + abstract={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.}, + keywords="DNS, E.164, NAPTR, dynamic delegation discovery system", + doi="10.17487/RFC5483", + } + +@misc{rfc5484, + author="D. Singer", + title="{Associating Time-Codes with RTP Streams}", + howpublished="RFC 5484 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5484", + pages="1--13", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5484.txt", + key="RFC 5484", + abstract={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]}, + keywords="smpte, society of motion picture and television engineers, media stream", + doi="10.17487/RFC5484", + } + +@misc{rfc5485, + author="R. Housley", + title="{Digital Signatures on Internet-Draft Documents}", + howpublished="RFC 5485 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5485", + pages="1--14", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8358", +url="https://www.rfc-editor.org/rfc/rfc5485.txt", + key="RFC 5485", + abstract={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.}, + keywords="cms, cryptographic message syntax, detached signature", + doi="10.17487/RFC5485", + } + +@misc{rfc5486, + author="D. {Malas (Ed.)} and D. {Meyer (Ed.)}", + title="{Session Peering for Multimedia Interconnect (SPEERMINT) Terminology}", + howpublished="RFC 5486 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5486", + pages="1--10", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5486.txt", + key="RFC 5486", + abstract={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.}, + doi="10.17487/RFC5486", + } + +@misc{rfc5487, + author="M. Badra", + title="{Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode}", + howpublished="RFC 5487 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5487", + pages="1--7", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5487.txt", + key="RFC 5487", + abstract={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]}, + keywords="PSK, Diffie-Hellman, Key Exchange, advanced encryption standard, gcm, digest algorithm, ciphersuite", + doi="10.17487/RFC5487", + } + +@misc{rfc5488, + author="S. Gundavelli and G. Keeni and K. Koide and K. Nagami", + title="{Network Mobility (NEMO) Management Information Base}", + howpublished="RFC 5488 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5488", + pages="1--44", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5488.txt", + key="RFC 5488", + abstract={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]}, + keywords="mib, NEMO-MIB", + doi="10.17487/RFC5488", + } + +@misc{rfc5489, + author="M. Badra and I. Hajjeh", + title="{ECDHE\_PSK Cipher Suites for Transport Layer Security (TLS)}", + howpublished="RFC 5489 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5489", + pages="1--7", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5489.txt", + key="RFC 5489", + abstract={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.}, + keywords="pre-shared key, Diffie-Hellman, Key Exchange, Elliptic Curve Cryptography", + doi="10.17487/RFC5489", + } + +@misc{rfc5490, + author="A. Melnikov", + title="{The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata}", + howpublished="RFC 5490 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5490", + pages="1--8", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5490.txt", + key="RFC 5490", + abstract={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]}, + keywords="mail filtering, fileinto", + doi="10.17487/RFC5490", + } + +@misc{rfc5491, + author="J. Winterbottom and M. Thomson and H. Tschofenig", + title="{GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations}", + howpublished="RFC 5491 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5491", + pages="1--28", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7459", +url="https://www.rfc-editor.org/rfc/rfc5491.txt", + key="RFC 5491", + abstract={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]}, + keywords="PIDF-LO, civic, geodetic, location, well-formed, GeoShape", + doi="10.17487/RFC5491", + } + +@misc{rfc5492, + author="J. Scudder and R. Chandra", + title="{Capabilities Advertisement with BGP-4}", + howpublished="RFC 5492 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5492", + pages="1--7", + year=2009, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5492.txt", + key="RFC 5492", + abstract={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. This document obsoletes RFC 3392. [STANDARDS-TRACK]}, + keywords="bgp, idr, border gateway protocol, capabilities", + doi="10.17487/RFC5492", + } + +@misc{rfc5493, + author="D. Caviglia and D. Bramanti and D. Li and D. McDysan", + title="{Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network}", + howpublished="RFC 5493 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5493", + pages="1--11", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5493.txt", + key="RFC 5493", + abstract={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. 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.}, + keywords="pc, spc, soft permanent connection, data plane traffic", + doi="10.17487/RFC5493", + } + +@misc{rfc5494, + author="J. Arkko and C. Pignataro", + title="{IANA Allocation Guidelines for the Address Resolution Protocol (ARP)}", + howpublished="RFC 5494 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5494", + pages="1--7", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5494.txt", + key="RFC 5494", + abstract={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]}, + keywords="IANA rules, Address Resolution Protocol, ARP", + doi="10.17487/RFC5494", + } + +@misc{rfc5495, + author="D. Li and J. Gao and A. Satyanarayana and S. Bardalai", + title="{Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures}", + howpublished="RFC 5495 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5495", + pages="1--18", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5495.txt", + key="RFC 5495", + abstract={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. 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). 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. 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 i n which the nodes restart is different. 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.}, + keywords="Hello message, gmpls", + doi="10.17487/RFC5495", + } + +@misc{rfc5496, + author="IJ. Wijnands and A. Boers and E. Rosen", + title="{The Reverse Path Forwarding (RPF) Vector TLV}", + howpublished="RFC 5496 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5496", + pages="1--8", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5496.txt", + key="RFC 5496", + abstract={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]}, + keywords="pim, protocol independent multicast join attribute", + doi="10.17487/RFC5496", + } + +@misc{rfc5497, + author="T. Clausen and C. Dearlove", + title="{Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)}", + howpublished="RFC 5497 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5497", + pages="1--14", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5497.txt", + key="RFC 5497", + abstract={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]}, + keywords="Routing Protocol, TLV, Fisheye, FSR, Fuzzy-Sighted, extension, packetbb, RFC5444", + doi="10.17487/RFC5497", + } + +@misc{rfc5498, + author="I. Chakeres", + title="{IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols}", + howpublished="RFC 5498 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5498", + pages="1--5", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5498.txt", + key="RFC 5498", + abstract={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]}, + keywords="manet protocols", + doi="10.17487/RFC5498", + } + +@misc{rfc5501, + author="Y. {Kamite (Ed.)} and Y. Wada and Y. Serbest and T. Morin and L. Fang", + title="{Requirements for Multicast Support in Virtual Private LAN Services}", + howpublished="RFC 5501 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5501", + pages="1--31", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5501.txt", + key="RFC 5501", + abstract={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.}, + keywords="L2, VPN, VPLS, Ethernet, P2MP, IGMP, MLD, PIM", + doi="10.17487/RFC5501", + } + +@misc{rfc5502, + author="J. van Elburg", + title="{The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem}", + howpublished="RFC 5502 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5502", + pages="1--14", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8217", +url="https://www.rfc-editor.org/rfc/rfc5502.txt", + key="RFC 5502", + abstract={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.}, + keywords="SIP, S-CSCF, AS, ISC", + doi="10.17487/RFC5502", + } + +@misc{rfc5503, + author="F. Andreasen and B. McKibben and B. Marshall", + title="{Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture}", + howpublished="RFC 5503 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5503", + pages="1--34", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5503.txt", + key="RFC 5503", + abstract={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 coordina tion of charging and other functions is required. This memo provides information for the Internet community.}, + keywords="P-DCS-TRACE-PARTY-ID, P-DCS-OSPS, P-DCS-BILLING-INFO, P-DCS-LAES, P-DCS-Redirect, P-DCS-INFO", + doi="10.17487/RFC5503", + } + +@misc{rfc5504, + author="K. {Fujiwara (Ed.)} and Y. {Yoneya (Ed.)}", + title="{Downgrading Mechanism for Email Address Internationalization}", + howpublished="RFC 5504 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5504", + pages="1--24", + year=2009, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6530", +url="https://www.rfc-editor.org/rfc/rfc5504.txt", + key="RFC 5504", + abstract={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.}, + keywords="EAI, Email Address Internationalization, Downgrade, MAIL", + doi="10.17487/RFC5504", + } + +@misc{rfc5505, + author="B. Aboba and D. Thaler and L. Andersson and S. Cheshire", + title="{Principles of Internet Host Configuration}", + howpublished="RFC 5505 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5505", + pages="1--25", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5505.txt", + key="RFC 5505", + abstract={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.}, + keywords="internet-layer parameter, higher-layer configuration", + doi="10.17487/RFC5505", + } + +@misc{rfc5506, + author="I. Johansson and M. Westerlund", + title="{Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences}", + howpublished="RFC 5506 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5506", + pages="1--17", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5506.txt", + key="RFC 5506", + abstract={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]}, + keywords="AVPF, non-compound, non compound, compound", + doi="10.17487/RFC5506", + } + +@misc{rfc5507, + author="IAB and P. {Faltstrom (Ed.)} and R. {Austein (Ed.)} and P. {Koch (Ed.)}", + title="{Design Choices When Expanding the DNS}", + howpublished="RFC 5507 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5507", + pages="1--18", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5507.txt", + key="RFC 5507", + abstract={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.}, + keywords="domain name system, resource record type", + doi="10.17487/RFC5507", + } + +@misc{rfc5508, + author="P. Srisuresh and B. Ford and S. Sivakumar and S. Guha", + title="{NAT Behavioral Requirements for ICMP}", + howpublished="RFC 5508 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5508", + pages="1--29", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7857", +url="https://www.rfc-editor.org/rfc/rfc5508.txt", + key="RFC 5508", + abstract={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.}, + keywords="ICMP Error payload translation, hairpin translation, ICMP Query, ICMP Error, Ping, Traceroute", + doi="10.17487/RFC5508", + } + +@misc{rfc5509, + author="S. Loreto", + title="{Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)}", + howpublished="RFC 5509 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5509", + pages="1--5", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5509.txt", + key="RFC 5509", + abstract={This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. [STANDARDS TRACK]}, + keywords="\_sip", + doi="10.17487/RFC5509", + } + +@misc{rfc5510, + author="J. Lacan and V. Roca and J. Peltotalo and S. Peltotalo", + title="{Reed-Solomon Forward Error Correction (FEC) Schemes}", + howpublished="RFC 5510 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5510", + pages="1--28", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5510.txt", + key="RFC 5510", + abstract={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). 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. [STAN DARDS-TRACK]}, + keywords="maximum distance separable, MDS", + doi="10.17487/RFC5510", + } + +@misc{rfc5511, + author="A. Farrel", + title="{Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications}", + howpublished="RFC 5511 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5511", + pages="1--14", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5511.txt", + key="RFC 5511", + abstract={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. 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. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. 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]}, + keywords="routing bnf", + doi="10.17487/RFC5511", + } + +@misc{rfc5512, + author="P. Mohapatra and E. Rosen", + title="{The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute}", + howpublished="RFC 5512 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5512", + pages="1--13", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5512.txt", + key="RFC 5512", + abstract={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. 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 enca psulation 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]}, + keywords="BGP, Encapsulation, Encap SAFI, Tunnel, Softwire, 4over6, 6over4", + doi="10.17487/RFC5512", + } + +@misc{rfc5513, + author="A. Farrel", + title="{IANA Considerations for Three Letter Acronyms}", + howpublished="RFC 5513 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5513", + pages="1--7", + year=2009, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5513.txt", + key="RFC 5513", + abstract={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. 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.}, + keywords="tla, abbreviation", + doi="10.17487/RFC5513", + } + +@misc{rfc5514, + author="E. Vyncke", + title="{IPv6 over Social Networks}", + howpublished="RFC 5514 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5514", + pages="1--6", + year=2009, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5514.txt", + key="RFC 5514", + abstract={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.}, + keywords="facebook", + doi="10.17487/RFC5514", + } + +@misc{rfc5515, + author="V. Mammoliti and C. Pignataro and P. Arberg and J. Gibbons and P. Howard", + title="{Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions}", + howpublished="RFC 5515 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5515", + pages="1--28", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5515.txt", + key="RFC 5515", + abstract={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.}, + keywords="L2TP, Acces Line Information, DSLAM", + doi="10.17487/RFC5515", + } + +@misc{rfc5516, + author="M. Jones and L. Morand", + title="{Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)}", + howpublished="RFC 5516 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5516", + pages="1--5", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5516.txt", + key="RFC 5516", + abstract={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.}, + keywords="3GPP, Release 8, Diameter, command codes, EPS", + doi="10.17487/RFC5516", + } + +@misc{rfc5517, + author="S. HomChaudhuri and M. Foschiano", + title="{Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment}", + howpublished="RFC 5517 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5517", + pages="1--12", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5517.txt", + key="RFC 5517", + abstract={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. 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.}, + doi="10.17487/RFC5517", + } + +@misc{rfc5518, + author="P. Hoffman and J. Levine and A. Hathcock", + title="{Vouch By Reference}", + howpublished="RFC 5518 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5518", + pages="1--12", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5518.txt", + key="RFC 5518", + abstract={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]}, + keywords="VBR, DKIM, SenderID, DK, reputation", + doi="10.17487/RFC5518", + } + +@misc{rfc5519, + author="J. Chesterfield and B. {Haberman (Ed.)}", + title="{Multicast Group Membership Discovery MIB}", + howpublished="RFC 5519 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5519", + pages="1--41", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5519.txt", + key="RFC 5519", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. [STANDARDS-TRACK]}, + keywords="management information base, mgmd, mld, multicast listener discovery, MGMD-STD-MIB", + doi="10.17487/RFC5519", + } + +@misc{rfc5520, + author="R. {Bradford (Ed.)} and JP. Vasseur and A. Farrel", + title="{Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism}", + howpublished="RFC 5520 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5520", + pages="1--19", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5520.txt", + key="RFC 5520", + abstract={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. 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]}, + keywords="confidential path segment, cps, pcep", + doi="10.17487/RFC5520", + } + +@misc{rfc5521, + author="E. Oki and T. Takeda and A. Farrel", + title="{Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions}", + howpublished="RFC 5521 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5521", + pages="1--16", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5521.txt", + key="RFC 5521", + abstract={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. 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''. 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]}, + keywords="MPLS, GMPLS, Traffic Engineering, Label Switched Path", + doi="10.17487/RFC5521", + } + +@misc{rfc5522, + author="W. Eddy and W. Ivancic and T. Davis", + title="{Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks}", + howpublished="RFC 5522 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5522", + pages="1--31", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5522.txt", + key="RFC 5522", + abstract={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. 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.}, + keywords="NEMO, aeronautics, space exploration, route optimization, mobility", + doi="10.17487/RFC5522", + } + +@misc{rfc5523, + author="L. Berger", + title="{OSPFv3-Based Layer 1 VPN Auto-Discovery}", + howpublished="RFC 5523 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5523", + pages="1--12", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5523.txt", + key="RFC 5523", + abstract={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.}, + keywords="open shortest path first, layer 1 virtual private network", + doi="10.17487/RFC5523", + } + +@misc{rfc5524, + author="D. Cridland", + title="{Extended URLFETCH for Binary and Converted Parts}", + howpublished="RFC 5524 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5524", + pages="1--9", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5524.txt", + key="RFC 5524", + abstract={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]}, + keywords="IMAP, Lemonade", + doi="10.17487/RFC5524", + } + +@misc{rfc5525, + author="T. Dreibholz and J. Mulik", + title="{Reliable Server Pooling MIB Module Definition}", + howpublished="RFC 5525 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5525", + pages="1--46", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5525.txt", + key="RFC 5525", + abstract={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.}, + keywords="RSerPool, Management Information Base, asap, aggregate server access protocol, enrp, endpoint handlespace redundancy protocol, RSERPOOL-MIB", + doi="10.17487/RFC5525", + } + +@misc{rfc5526, + author="J. Livingood and P. Pfautz and R. Stastny", + title="{The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM}", + howpublished="RFC 5526 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5526", + pages="1--5", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5526.txt", + key="RFC 5526", + abstract={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.}, + keywords="e164.arpa", + doi="10.17487/RFC5526", + } + +@misc{rfc5527, + author="M. Haberler and O. Lendl and R. Stastny", + title="{Combined User and Infrastructure ENUM in the e164.arpa Tree}", + howpublished="RFC 5527 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5527", + pages="1--10", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5527.txt", + key="RFC 5527", + abstract={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.}, + keywords="e164.arpa", + doi="10.17487/RFC5527", + } + +@misc{rfc5528, + author="A. Kato and M. Kanda and S. Kanno", + title="{Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms}", + howpublished="RFC 5528 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5528", + pages="1--22", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5528.txt", + key="RFC 5528", + abstract={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.}, + keywords="Camellia, Block Cipher, Mode of operation", + doi="10.17487/RFC5528", + } + +@misc{rfc5529, + author="A. Kato and M. Kanda and S. Kanno", + title="{Modes of Operation for Camellia for Use with IPsec}", + howpublished="RFC 5529 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5529", + pages="1--7", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5529.txt", + key="RFC 5529", + abstract={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]}, + keywords="IPsec, Camellia, Block Cipher, Mode of operation", + doi="10.17487/RFC5529", + } + +@misc{rfc5530, + author="A. Gulbrandsen", + title="{IMAP Response Codes}", + howpublished="RFC 5530 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5530", + pages="1--9", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5530.txt", + key="RFC 5530", + abstract={IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text. This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]}, + keywords="machine-readable response codes", + doi="10.17487/RFC5530", + } + +@misc{rfc5531, + author="R. Thurlow", + title="{RPC: Remote Procedure Call Protocol Specification Version 2}", + howpublished="RFC 5531 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5531", + pages="1--63", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5531.txt", + key="RFC 5531", + abstract={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]}, + keywords="RPC, ONC, Open Network Computing", + doi="10.17487/RFC5531", + } + +@misc{rfc5532, + author="T. Talpey and C. Juszczak", + title="{Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement}", + howpublished="RFC 5532 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5532", + pages="1--15", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5532.txt", + key="RFC 5532", + abstract={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.}, + keywords="RPC, XDR, ONC, RDDP, NFSv4", + doi="10.17487/RFC5532", + } + +@misc{rfc5533, + author="E. Nordmark and M. Bagnulo", + title="{Shim6: Level 3 Multihoming Shim Protocol for IPv6}", + howpublished="RFC 5533 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5533", + pages="1--124", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5533.txt", + key="RFC 5533", + abstract={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]}, + keywords="locator pair", + doi="10.17487/RFC5533", + } + +@misc{rfc5534, + author="J. Arkko and I. van Beijnum", + title="{Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming}", + howpublished="RFC 5534 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5534", + pages="1--36", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5534.txt", + key="RFC 5534", + abstract={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]}, + keywords="Shim6, reachability protocol, REAP", + doi="10.17487/RFC5534", + } + +@misc{rfc5535, + author="M. Bagnulo", + title="{Hash-Based Addresses (HBA)}", + howpublished="RFC 5535 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5535", + pages="1--25", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5535.txt", + key="RFC 5535", + abstract={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]}, + keywords="Shim6, multi-homing, cryptographically generated addresses (cgas),", + doi="10.17487/RFC5535", + } + +@misc{rfc5536, + author="K. {Murchison (Ed.)} and C. Lindsey and D. Kohn", + title="{Netnews Article Format}", + howpublished="RFC 5536 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5536", + pages="1--36", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5536.txt", + key="RFC 5536", + abstract={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]}, + keywords="Usenet, Usefor", + doi="10.17487/RFC5536", + } + +@misc{rfc5537, + author="R. {Allbery (Ed.)} and C. Lindsey", + title="{Netnews Architecture and Protocols}", + howpublished="RFC 5537 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5537", + pages="1--48", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8315", +url="https://www.rfc-editor.org/rfc/rfc5537.txt", + key="RFC 5537", + abstract={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]}, + keywords="usefor, Usenet, netnews", + doi="10.17487/RFC5537", + } + +@misc{rfc5538, + author="F. Ellermann", + title="{The 'news' and 'nntp' URI Schemes}", + howpublished="RFC 5538 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5538", + pages="1--14", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5538.txt", + key="RFC 5538", + abstract={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]}, + doi="10.17487/RFC5538", + } + +@misc{rfc5539, + author="M. Badra", + title="{NETCONF over Transport Layer Security (TLS)}", + howpublished="RFC 5539 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5539", + pages="1--7", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7589", +url="https://www.rfc-editor.org/rfc/rfc5539.txt", + key="RFC 5539", + abstract={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]}, + keywords="Authentication, TLS, RPC", + doi="10.17487/RFC5539", + } + +@misc{rfc5540, + author="RFC Editor", + title="{40 Years of RFCs}", + howpublished="RFC 5540 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5540", + pages="1--3", + year=2009, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5540.txt", + key="RFC 5540", + abstract={This RFC marks the 40th anniversary of the RFC document series. This memo provides information for the Internet community.}, + doi="10.17487/RFC5540", + } + +@misc{rfc5541, + author="JL. Le Roux and JP. Vasseur and Y. Lee", + title="{Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)}", + howpublished="RFC 5541 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5541", + pages="1--23", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5541.txt", + key="RFC 5541", + abstract={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.). 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. 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 in dicate 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. 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]}, + keywords="pcc, path computation client", + doi="10.17487/RFC5541", + } + +@misc{rfc5542, + author="T. {Nadeau (Ed.)} and D. {Zelig (Ed.)} and O. {Nicklass (Ed.)}", + title="{Definitions of Textual Conventions for Pseudowire (PW) Management}", + howpublished="RFC 5542 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5542", + pages="1--11", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5542.txt", + key="RFC 5542", + abstract={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]}, + keywords="Pseudowire, PWE3, MIB, PWE3-TC, PW-TC", + doi="10.17487/RFC5542", + } + +@misc{rfc5543, + author="H. Ould-Brahim and D. Fedyk and Y. Rekhter", + title="{BGP Traffic Engineering Attribute}", + howpublished="RFC 5543 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5543", + pages="1--6", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7606", +url="https://www.rfc-editor.org/rfc/rfc5543.txt", + key="RFC 5543", + abstract={This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information. The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]}, + keywords="BGP-TE, BGP-TE Attribute, Traffic Engineering with BGP, Inter-domain Traffic Engineering, L1VPN BGP-TE, BGP-TE-VPN, VPN BGP Traffic Engineering Attribute", + doi="10.17487/RFC5543", + } + +@misc{rfc5544, + author="A. Santoni", + title="{Syntax for Binding Documents with Time-Stamps}", + howpublished="RFC 5544 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5544", + pages="1--13", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 5955", +url="https://www.rfc-editor.org/rfc/rfc5544.txt", + key="RFC 5544", + abstract={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. 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.}, + keywords="time-stamp token,", + doi="10.17487/RFC5544", + } + +@misc{rfc5545, + author="B. {Desruisseaux (Ed.)}", + title="{Internet Calendaring and Scheduling Core Object Specification (iCalendar)}", + howpublished="RFC 5545 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5545", + pages="1--168", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 5546, 6868, 7529, 7953, 7986", +url="https://www.rfc-editor.org/rfc/rfc5545.txt", + key="RFC 5545", + abstract={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]}, + keywords="calsify, calsched, calsch, caldav, calendar, calendaring, meeting, event, task, to-do, journal, appointment, agenda, schedule, scheduling, ical, icalendar, itip, imip, text/calendar, ischedule, xCalendar", + doi="10.17487/RFC5545", + } + +@misc{rfc5546, + author="C. {Daboo (Ed.)}", + title="{iCalendar Transport-Independent Interoperability Protocol (iTIP)}", + howpublished="RFC 5546 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5546", + pages="1--133", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6638", +url="https://www.rfc-editor.org/rfc/rfc5546.txt", + key="RFC 5546", + abstract={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. 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]}, + keywords="calendar, scheduling", + doi="10.17487/RFC5546", + } + +@misc{rfc5547, + author="M. Garcia-Martin and M. Isomaki and G. Camarillo and S. Loreto and P. Kyzivat", + title="{A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer}", + howpublished="RFC 5547 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5547", + pages="1--50", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5547.txt", + key="RFC 5547", + abstract={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]}, + keywords="msrp, message session relay protocol", + doi="10.17487/RFC5547", + } + +@misc{rfc5548, + author="M. {Dohler (Ed.)} and T. {Watteyne (Ed.)} and T. {Winter (Ed.)} and D. {Barthel (Ed.)}", + title="{Routing Requirements for Urban Low-Power and Lossy Networks}", + howpublished="RFC 5548 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5548", + pages="1--21", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5548.txt", + key="RFC 5548", + abstract={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.}, + keywords="u-lln, roll, routing over low-power and loss", + doi="10.17487/RFC5548", + } + +@misc{rfc5549, + author="F. Le Faucheur and E. Rosen", + title="{Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop}", + howpublished="RFC 5549 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5549", + pages="1--10", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5549.txt", + key="RFC 5549", + abstract={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 wheth er they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]}, + keywords="BGP, IPv6, IPv4", + doi="10.17487/RFC5549", + } + +@misc{rfc5550, + author="D. {Cridland (Ed.)} and A. {Melnikov (Ed.)} and S. {Maes (Ed.)}", + title="{The Internet Email to Support Diverse Service Environments (Lemonade) Profile}", + howpublished="RFC 5550 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5550", + pages="1--41", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5550.txt", + key="RFC 5550", + abstract={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. 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]}, + keywords="IMAP, Sieve, SMTP, Lemonade, mobile email, low-bandwidth efficient", + doi="10.17487/RFC5550", + } + +@misc{rfc5551, + author="R. {Gellens (Ed.)}", + title="{Lemonade Notifications Architecture}", + howpublished="RFC 5551 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5551", + pages="1--12", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5551.txt", + key="RFC 5551", + abstract={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. 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.}, + keywords="notification, filtering", + doi="10.17487/RFC5551", + } + +@misc{rfc5552, + author="D. Burke and M. Scott", + title="{SIP Interface to VoiceXML Media Services}", + howpublished="RFC 5552 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5552", + pages="1--36", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5552.txt", + key="RFC 5552", + abstract={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]}, + keywords="VoiceXML, SIP, MRF, IVR, IMS", + doi="10.17487/RFC5552", + } + +@misc{rfc5553, + author="A. {Farrel (Ed.)} and R. Bradford and JP. Vasseur", + title="{Resource Reservation Protocol (RSVP) Extensions for Path Key Support}", + howpublished="RFC 5553 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5553", + pages="1--14", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5553.txt", + key="RFC 5553", + abstract={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. 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. 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. [S TANDARDS-TRACK]}, + keywords="pks, path key subobject, ero, explicit route object, rro, record route object", + doi="10.17487/RFC5553", + } + +@misc{rfc5554, + author="N. Williams", + title="{Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings}", + howpublished="RFC 5554 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5554", + pages="1--4", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5554.txt", + key="RFC 5554", + abstract={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]}, + keywords="GSS, GSS-API, channel binding, and C-bindings", + doi="10.17487/RFC5554", + } + +@misc{rfc5555, + author="H. {Soliman (Ed.)}", + title="{Mobile IPv6 Support for Dual Stack Hosts and Routers}", + howpublished="RFC 5555 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5555", + pages="1--41", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5555.txt", + key="RFC 5555", + abstract={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]}, + keywords="nemo, mipv6, ipv4", + doi="10.17487/RFC5555", + } + +@misc{rfc5556, + author="J. Touch and R. Perlman", + title="{Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement}", + howpublished="RFC 5556 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5556", + pages="1--17", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5556.txt", + key="RFC 5556", + abstract={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.}, + keywords="spanning tree protocol, ieee 802.1", + doi="10.17487/RFC5556", + } + +@misc{rfc5557, + author="Y. Lee and JL. Le Roux and D. King and E. Oki", + title="{Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization}", + howpublished="RFC 5557 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5557", + pages="1--26", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5557.txt", + key="RFC 5557", + abstract={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. This document provides application-specific re quirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]}, + keywords="pcc, path communication client, pce, gco, global concurrent optimization, nms, network management system", + doi="10.17487/RFC5557", + } + +@misc{rfc5558, + author="F. {Templin (Ed.)}", + title="{Virtual Enterprise Traversal (VET)}", + howpublished="RFC 5558 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5558", + pages="1--36", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5558.txt", + key="RFC 5558", + abstract={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.}, + keywords="Enterprise, MANET, Encapsulation, Tunneling, Autoconfiguration, Subnetwork, Provider-Independent, Provider-Aggregated", + doi="10.17487/RFC5558", + } + +@misc{rfc5559, + author="P. {Eardley (Ed.)}", + title="{Pre-Congestion Notification (PCN) Architecture}", + howpublished="RFC 5559 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5559", + pages="1--54", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5559.txt", + key="RFC 5559", + abstract={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.}, + keywords="Quality of Service, QoS, Congestion Control, Differentiated Services, Admission Control, Termination", + doi="10.17487/RFC5559", + } + +@misc{rfc5560, + author="H. Uijterwaal", + title="{A One-Way Packet Duplication Metric}", + howpublished="RFC 5560 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5560", + pages="1--14", + year=2009, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6248", +url="https://www.rfc-editor.org/rfc/rfc5560.txt", + key="RFC 5560", + abstract={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. 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]}, + keywords="performance metrics, packet duplication, unidirectional", + doi="10.17487/RFC5560", + } + +@misc{rfc5561, + author="B. Thomas and K. Raza and S. Aggarwal and R. Aggarwal and JL. Le Roux", + title="{LDP Capabilities}", + howpublished="RFC 5561 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5561", + pages="1--12", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5561.txt", + key="RFC 5561", + abstract={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]}, + keywords="MPLS, LDP, Capabilities", + doi="10.17487/RFC5561", + } + +@misc{rfc5562, + author="A. Kuzmanovic and A. Mondal and S. Floyd and K. Ramakrishnan", + title="{Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets}", + howpublished="RFC 5562 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5562", + pages="1--33", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5562.txt", + key="RFC 5562", + abstract={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. 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.}, + keywords="ecn-capable", + doi="10.17487/RFC5562", + } + +@misc{rfc5563, + author="K. Leung and G. Dommety and P. Yegani and K. Chowdhury", + title="{WiMAX Forum / 3GPP2 Proxy Mobile IPv4}", + howpublished="RFC 5563 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5563", + pages="1--41", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5563.txt", + key="RFC 5563", + abstract={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.}, + keywords="mipv4, pmipv4", + doi="10.17487/RFC5563", + } + +@misc{rfc5564, + author="A. El-Sherbiny and M. Farah and I. Oueichek and A. Al-Zoman", + title="{Linguistic Guidelines for the Use of the Arabic Language in Internet Domains}", + howpublished="RFC 5564 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5564", + pages="1--11", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5564.txt", + key="RFC 5564", + abstract={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.}, + keywords="arabic domain names", + doi="10.17487/RFC5564", + } + +@misc{rfc5565, + author="J. Wu and Y. Cui and C. Metz and E. Rosen", + title="{Softwire Mesh Framework}", + howpublished="RFC 5565 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5565", + pages="1--31", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5565.txt", + key="RFC 5565", + abstract={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]}, + keywords="", + doi="10.17487/RFC5565", + } + +@misc{rfc5566, + author="L. Berger and R. White and E. Rosen", + title="{BGP IPsec Tunnel Encapsulation Attribute}", + howpublished="RFC 5566 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5566", + pages="1--8", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5566.txt", + key="RFC 5566", + abstract={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]}, + keywords="border gateway protocol, safi, subsequent address family identifier", + doi="10.17487/RFC5566", + } + +@misc{rfc5567, + author="T. {Melanchuk (Ed.)}", + title="{An Architectural Framework for Media Server Control}", + howpublished="RFC 5567 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5567", + pages="1--25", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5567.txt", + key="RFC 5567", + abstract={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.}, + doi="10.17487/RFC5567", + } + +@misc{rfc5568, + author="R. {Koodli (Ed.)}", + title="{Mobile IPv6 Fast Handovers}", + howpublished="RFC 5568 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5568", + pages="1--51", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7411", +url="https://www.rfc-editor.org/rfc/rfc5568.txt", + key="RFC 5568", + abstract={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. This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. [STANDARDS-T RACK]}, + keywords="mpiv6, handover latency", + doi="10.17487/RFC5568", + } + +@misc{rfc5569, + author="R. Despres", + title="{IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)}", + howpublished="RFC 5569 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5569", + pages="1--10", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5569.txt", + key="RFC 5569", + abstract={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.}, + keywords="IPv6, IPv4, migration, transition, 6to4, 6rd", + doi="10.17487/RFC5569", + } + +@misc{rfc5570, + author="M. StJohns and R. Atkinson and G. Thomas", + title="{Common Architecture Label IPv6 Security Option (CALIPSO)}", + howpublished="RFC 5570 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5570", + pages="1--52", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5570.txt", + key="RFC 5570", + abstract={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.}, + keywords="sensitivity labels, mls, multi-level secure", + doi="10.17487/RFC5570", + } + +@misc{rfc5571, + author="B. Storer and C. {Pignataro (Ed.)} and M. Dos Santos and B. {Stevant (Ed.)} and L. Toutain and J. Tremblay", + title="{Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)}", + howpublished="RFC 5571 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5571", + pages="1--41", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5571.txt", + key="RFC 5571", + abstract={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]}, + keywords="Softwire, L2TP, Softwire Hub and Spoke, Softwire HnS, 4over6, 6over4, L2TP softwires, L2TPv2 softwires", + doi="10.17487/RFC5571", + } + +@misc{rfc5572, + author="M. Blanchet and F. Parent", + title="{IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)}", + howpublished="RFC 5572 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5572", + pages="1--32", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5572.txt", + key="RFC 5572", + abstract={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.}, + keywords="IPv6, Tunnel, Transition, TSP", + doi="10.17487/RFC5572", + } + +@misc{rfc5573, + author="M. Thomson", + title="{Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)}", + howpublished="RFC 5573 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5573", + pages="1--8", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5573.txt", + key="RFC 5573", + abstract={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.}, + keywords="asynchronous beep channels", + doi="10.17487/RFC5573", + } + +@misc{rfc5574, + author="G. Herlein and J. Valin and A. Heggestad and A. Moizard", + title="{RTP Payload Format for the Speex Codec}", + howpublished="RFC 5574 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5574", + pages="1--14", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5574.txt", + key="RFC 5574", + abstract={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]}, + keywords="Voip, SDP, audio, CELLP, Xiph.Org", + doi="10.17487/RFC5574", + } + +@misc{rfc5575, + author="P. Marques and N. Sheth and R. Raszuk and B. Greene and J. Mauch and D. McPherson", + title="{Dissemination of Flow Specification Rules}", + howpublished="RFC 5575 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5575", + pages="1--22", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7674", +url="https://www.rfc-editor.org/rfc/rfc5575.txt", + key="RFC 5575", + abstract={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. 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. The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]}, + keywords="IDR, Inter-domain routing, BGP, DDOS, Denial of Service, ACL, Firewall, Filter", + doi="10.17487/RFC5575", + } + +@misc{rfc5576, + author="J. Lennox and J. Ott and T. Schierl", + title="{Source-Specific Media Attributes in the Session Description Protocol (SDP)}", + howpublished="RFC 5576 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5576", + pages="1--18", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5576.txt", + key="RFC 5576", + abstract={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]}, + keywords="real-time transport protocol, rtp, synchronization source, ssrc, fid, flow identification, fec, forward error correction", + doi="10.17487/RFC5576", + } + +@misc{rfc5577, + author="P. Luthi and R. Even", + title="{RTP Payload Format for ITU-T Recommendation G.722.1}", + howpublished="RFC 5577 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5577", + pages="1--11", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5577.txt", + key="RFC 5577", + abstract={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]}, + keywords="international telecommunication union, wide-band audio coded", + doi="10.17487/RFC5577", + } + +@misc{rfc5578, + author="B. {Berry (Ed.)} and S. Ratliff and E. Paradise and T. Kaiser and M. Adams", + title="{PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics}", + howpublished="RFC 5578 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5578", + pages="1--24", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5578.txt", + key="RFC 5578", + abstract={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.}, + keywords="point-to-point protocol over ethernet, link quality metric", + doi="10.17487/RFC5578", + } + +@misc{rfc5579, + author="F. {Templin (Ed.)}", + title="{Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces}", + howpublished="RFC 5579 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5579", + pages="1--9", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5579.txt", + key="RFC 5579", + abstract={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.}, + keywords="ISATAP, Tunnel, Encapsulation, Map-and-Encaps, IPv4, IPv6", + doi="10.17487/RFC5579", + } + +@misc{rfc5580, + author="H. {Tschofenig (Ed.)} and F. Adrangi and M. Jones and A. Lior and B. Aboba", + title="{Carrying Location Objects in RADIUS and Diameter}", + howpublished="RFC 5580 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5580", + pages="1--53", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5580.txt", + key="RFC 5580", + abstract={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. 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]}, + keywords="remote authentication dial-in user service, location information", + doi="10.17487/RFC5580", + } + +@misc{rfc5581, + author="D. Shaw", + title="{The Camellia Cipher in OpenPGP}", + howpublished="RFC 5581 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5581", + pages="1--3", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5581.txt", + key="RFC 5581", + abstract={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.}, + keywords="PGP, GPG, GnuPG, Encryption, Symmetric", + doi="10.17487/RFC5581", + } + +@misc{rfc5582, + author="H. Schulzrinne", + title="{Location-to-URL Mapping Architecture and Framework}", + howpublished="RFC 5582 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5582", + pages="1--17", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5582.txt", + key="RFC 5582", + abstract={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.}, + keywords="ECRIT, Mapping, LoST, Emergency calling", + doi="10.17487/RFC5582", + } + +@misc{rfc5583, + author="T. Schierl and S. Wenger", + title="{Signaling Media Decoding Dependency in the Session Description Protocol (SDP)}", + howpublished="RFC 5583 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5583", + pages="1--18", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5583.txt", + key="RFC 5583", + abstract={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. 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]}, + keywords="media coding, ddp, decoding dependency", + doi="10.17487/RFC5583", + } + +@misc{rfc5584, + author="M. Hatanaka and J. Matsumoto", + title="{RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family}", + howpublished="RFC 5584 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5584", + pages="1--30", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5584.txt", + key="RFC 5584", + abstract={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]}, + keywords="RTP, audio, fragmentation, layered coding, multiplexed, multi-session, multi-channel, redundancy, scalable, ATRAC, ATRAC3, ATRAC-X, ATRAC Advanced Lossless, AAL, Sony Corporation", + doi="10.17487/RFC5584", + } + +@misc{rfc5585, + author="T. Hansen and D. Crocker and P. Hallam-Baker", + title="{DomainKeys Identified Mail (DKIM) Service Overview}", + howpublished="RFC 5585 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5585", + pages="1--24", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5585.txt", + key="RFC 5585", + abstract={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 potent ial 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.}, + keywords="Email, Electroni Mail, Internet Mail, Message Verification", + doi="10.17487/RFC5585", + } + +@misc{rfc5586, + author="M. {Bocci (Ed.)} and M. {Vigoureux (Ed.)} and S. {Bryant (Ed.)}", + title="{MPLS Generic Associated Channel}", + howpublished="RFC 5586 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5586", + pages="1--19", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6423, 7026, 7214, 7274", +url="https://www.rfc-editor.org/rfc/rfc5586.txt", + key="RFC 5586", + abstract={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.}, + keywords="mpls-tp, oam, g-ach, ach, associated channel header, gal, generic associated label", + doi="10.17487/RFC5586", + } + +@misc{rfc5587, + author="N. Williams", + title="{Extended Generic Security Service Mechanism Inquiry APIs}", + howpublished="RFC 5587 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5587", + pages="1--16", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5587.txt", + key="RFC 5587", + abstract={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. 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]}, + keywords="GSS-API, mechanism, inquiry, extension", + doi="10.17487/RFC5587", + } + +@misc{rfc5588, + author="N. Williams", + title="{Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials}", + howpublished="RFC 5588 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5588", + pages="1--7", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5588.txt", + key="RFC 5588", + abstract={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]}, + keywords="GSS-API, credential, gss\_store\_cred", + doi="10.17487/RFC5588", + } + +@misc{rfc5589, + author="R. Sparks and A. {Johnston (Ed.)} and D. Petrie", + title="{Session Initiation Protocol (SIP) Call Control - Transfer}", + howpublished="RFC 5589 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5589", + pages="1--58", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5589.txt", + key="RFC 5589", + abstract={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.}, + keywords="REFER, GRUU, Attended Transfer, Target-Dialog, Out of Dialog REFER, SIP, SIP Services, blind transfer, SIP Features, Replaces, Referred-By", + doi="10.17487/RFC5589", + } + +@misc{rfc5590, + author="D. Harrington and J. Schoenwaelder", + title="{Transport Subsystem for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 5590 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5590", + pages="1--34", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5590.txt", + key="RFC 5590", + abstract={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]}, + keywords="Network Management, Simple Network Management Protocol, SNMP, SNMP-TRANSPORT-MIB", + doi="10.17487/RFC5590", + } + +@misc{rfc5591, + author="D. Harrington and W. Hardaker", + title="{Transport Security Model for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 5591 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5591", + pages="1--28", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5591.txt", + key="RFC 5591", + abstract={This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP). This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Transport Security Model, Security Model", + doi="10.17487/RFC5591", + } + +@misc{rfc5592, + author="D. Harrington and J. Salowey and W. Hardaker", + title="{Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 5592 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5592", + pages="1--36", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5592.txt", + key="RFC 5592", + abstract={This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol. 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]}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Secure Shell, SSH", + doi="10.17487/RFC5592", + } + +@misc{rfc5593, + author="N. Cook", + title="{Internet Message Access Protocol (IMAP) - URL Access Identifier Extension}", + howpublished="RFC 5593 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5593", + pages="1--10", + year=2009, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5593.txt", + key="RFC 5593", + abstract={The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> 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 <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications. This document updates RFC 5092. [STANDARDS-TRACK]}, + keywords="urlauth, imap url", + doi="10.17487/RFC5593", + } + +@misc{rfc5594, + author="J. Peterson and A. Cooper", + title="{Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008}", + howpublished="RFC 5594 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5594", + pages="1--28", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5594.txt", + key="RFC 5594", + abstract={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.}, + keywords="P2PI", + doi="10.17487/RFC5594", + } + +@misc{rfc5595, + author="G. Fairhurst", + title="{The Datagram Congestion Control Protocol (DCCP) Service Codes}", + howpublished="RFC 5595 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5595", + pages="1--19", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6335", +url="https://www.rfc-editor.org/rfc/rfc5595.txt", + key="RFC 5595", + abstract={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]}, + keywords="DCCP-Request Ports", + doi="10.17487/RFC5595", + } + +@misc{rfc5596, + author="G. Fairhurst", + title="{Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal}", + howpublished="RFC 5596 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5596", + pages="1--25", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5596.txt", + key="RFC 5596", + abstract={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]}, + keywords="DCCP, NAT traversal, Middlebox Issues", + doi="10.17487/RFC5596", + } + +@misc{rfc5597, + author="R. Denis-Courmont", + title="{Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol}", + howpublished="RFC 5597 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5597", + pages="1--9", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5597.txt", + key="RFC 5597", + abstract={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.}, + keywords="dccp", + doi="10.17487/RFC5597", + } + +@misc{rfc5598, + author="D. Crocker", + title="{Internet Mail Architecture}", + howpublished="RFC 5598 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5598", + pages="1--54", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5598.txt", + key="RFC 5598", + abstract={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.}, + keywords="email, e-mail, service, mime, architecture, mta, mua, msa, mda, admd, user, originator, recipient, transfer, message transfer, deliver, delivery, relay, header, gateway agent, gateway actor, gateway, sieve, dsn, mdn, tussle, mhs, Message handling service, message transfer agent, message user agent, mail submission agent, mail delivery agent, administrative management domain", + doi="10.17487/RFC5598", + } + +@misc{rfc5601, + author="T. {Nadeau (Ed.)} and D. {Zelig (Ed.)}", + title="{Pseudowire (PW) Management Information Base (MIB)}", + howpublished="RFC 5601 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5601", + pages="1--67", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5601.txt", + key="RFC 5601", + abstract={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]}, + keywords="pseudowire edge-to-edge services, IANA-PWE3-MIB, PW-STD-MIB", + doi="10.17487/RFC5601", + } + +@misc{rfc5602, + author="D. {Zelig (Ed.)} and T. {Nadeau (Ed.)}", + title="{Pseudowire (PW) over MPLS PSN Management Information Base (MIB)}", + howpublished="RFC 5602 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5602", + pages="1--31", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5602.txt", + key="RFC 5602", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]}, + keywords="pw operation, PW-MPLS-STD-MIB", + doi="10.17487/RFC5602", + } + +@misc{rfc5603, + author="D. {Zelig (Ed.)} and T. {Nadeau (Ed.)}", + title="{Ethernet Pseudowire (PW) Management Information Base (MIB)}", + howpublished="RFC 5603 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5603", + pages="1--23", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5603.txt", + key="RFC 5603", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]}, + keywords="ethernet pw, PW-ENET-STD-MIB", + doi="10.17487/RFC5603", + } + +@misc{rfc5604, + author="O. Nicklass", + title="{Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)}", + howpublished="RFC 5604 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5604", + pages="1--41", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5604.txt", + key="RFC 5604", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]}, + keywords="mib, management information base, pseudowire encapsulation, t1, e1, t3, e3", + doi="10.17487/RFC5604", + } + +@misc{rfc5605, + author="O. Nicklass and T. Nadeau", + title="{Managed Objects for ATM over Packet Switched Networks (PSNs)}", + howpublished="RFC 5605 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5605", + pages="1--36", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5605.txt", + key="RFC 5605", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]}, + keywords="mib, management information base, atm pseudowire", + doi="10.17487/RFC5605", + } + +@misc{rfc5606, + author="J. Peterson and T. Hardie and J. Morris", + title="{Implications of 'retransmission-allowed' for SIP Location Conveyance}", + howpublished="RFC 5606 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5606", + pages="1--11", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5606.txt", + key="RFC 5606", + abstract={This document explores an ambiguity in the interpretation of the <retransmission-allowed> 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. 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.}, + keywords="pidf-lo, presence information data format for location objects", + doi="10.17487/RFC5606", + } + +@misc{rfc5607, + author="D. Nelson and G. Weber", + title="{Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management}", + howpublished="RFC 5607 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5607", + pages="1--25", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5607.txt", + key="RFC 5607", + abstract={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]}, + keywords="Network Management, Device Management, Simple Network Management Protocol, SNMP, Network Configuration Protocol, NETCONF, Access Control", + doi="10.17487/RFC5607", + } + +@misc{rfc5608, + author="K. Narayan and D. Nelson", + title="{Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models}", + howpublished="RFC 5608 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5608", + pages="1--14", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5608.txt", + key="RFC 5608", + abstract={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]}, + keywords="authorization service, ssh transport model, secure shell transport model", + doi="10.17487/RFC5608", + } + +@misc{rfc5609, + author="V. {Fajardo (Ed.)} and Y. Ohba and R. Marin-Lopez", + title="{State Machines for the Protocol for Carrying Authentication for Network Access (PANA)}", + howpublished="RFC 5609 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5609", + pages="1--30", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5609.txt", + key="RFC 5609", + abstract={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.}, + keywords="PANA, State Machine, EAP", + doi="10.17487/RFC5609", + } + +@misc{rfc5610, + author="E. Boschi and B. Trammell and L. Mark and T. Zseby", + title="{Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements}", + howpublished="RFC 5610 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5610", + pages="1--20", + year=2009, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5610.txt", + key="RFC 5610", + abstract={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]}, + keywords="enterprise-specific Information Element, IPFIX Template, type record, type options template", + doi="10.17487/RFC5610", + } + +@misc{rfc5611, + author="A. Vainshtein and S. Galtzur", + title="{Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires}", + howpublished="RFC 5611 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5611", + pages="1--11", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5611.txt", + key="RFC 5611", + abstract={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]}, + keywords="l2tpv3, layer tow tunneling protocol version 3, structure-agnostic, structure-aware, cesopsn, tdmoip", + doi="10.17487/RFC5611", + } + +@misc{rfc5612, + author="P. Eronen and D. Harrington", + title="{Enterprise Number for Documentation Use}", + howpublished="RFC 5612 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5612", + pages="1--4", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5612.txt", + key="RFC 5612", + abstract={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.}, + keywords="smi network management private enterprise code", + doi="10.17487/RFC5612", + } + +@misc{rfc5613, + author="A. Zinin and A. Roy and L. Nguyen and B. Friedman and D. Yeung", + title="{OSPF Link-Local Signaling}", + howpublished="RFC 5613 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5613", + pages="1--12", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5613.txt", + key="RFC 5613", + abstract={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.}, + keywords="open shortest path first, intra-domain routing", + doi="10.17487/RFC5613", + } + +@misc{rfc5614, + author="R. Ogier and P. Spagnolo", + title="{Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding}", + howpublished="RFC 5614 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5614", + pages="1--71", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7038", +url="https://www.rfc-editor.org/rfc/rfc5614.txt", + key="RFC 5614", + abstract={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.}, + keywords="MANET routing, link-state routing, CDS flooding, mesh network, MANET Designated Router, MDR", + doi="10.17487/RFC5614", + } + +@misc{rfc5615, + author="C. Groves and Y. Lin", + title="{H.248/MEGACO Registration Procedures}", + howpublished="RFC 5615 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5615", + pages="1--14", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5615.txt", + key="RFC 5615", + abstract={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.}, + keywords="Package, Error Code, ServiceChange Reason, Profile", + doi="10.17487/RFC5615", + } + +@misc{rfc5616, + author="N. Cook", + title="{Streaming Internet Messaging Attachments}", + howpublished="RFC 5616 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5616", + pages="1--28", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5616.txt", + key="RFC 5616", + abstract={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. 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.}, + keywords="IMAP, SIP, streaming, stream, email, multimedia, lemonade, attachments, video, audio", + doi="10.17487/RFC5616", + } + +@misc{rfc5617, + author="E. Allman and J. Fenton and M. Delany and J. Levine", + title="{DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)}", + howpublished="RFC 5617 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5617", + pages="1--21", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5617.txt", + key="RFC 5617", + abstract={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]}, + keywords="email, e-mail, rfc 5322, rfc 5322, rfc 822, rfc 822, rfc 5321, rfc 5321, rfc 821, rfc 821, rfc 4871, rfc 4871, DKIM, domain keys, domainkeys, ADSP, ADSP, SSP, architecture, mta, user, delivery, smtp, submission, email, e-mail, smtp, Internet, mailfrom, mail from, author, return address, sender signing, signing practices", + doi="10.17487/RFC5617", + } + +@misc{rfc5618, + author="A. Morton and K. Hedayat", + title="{Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)}", + howpublished="RFC 5618 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5618", + pages="1--8", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5618.txt", + key="RFC 5618", + abstract={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]}, + keywords="twamp-control protocol, twamp-test protocol, twamp modes", + doi="10.17487/RFC5618", + } + +@misc{rfc5619, + author="S. Yamamoto and C. Williams and H. Yokota and F. Parent", + title="{Softwire Security Analysis and Requirements}", + howpublished="RFC 5619 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5619", + pages="1--28", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5619.txt", + key="RFC 5619", + abstract={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]}, + keywords="IPv6, Tunnel, Softwire, Transition", + doi="10.17487/RFC5619", + } + +@misc{rfc5620, + author="O. {Kolkman (Ed.)} and IAB", + title="{RFC Editor Model (Version 1)}", + howpublished="RFC 5620 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5620", + pages="1--19", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFCs 6548, 6635", +url="https://www.rfc-editor.org/rfc/rfc5620.txt", + key="RFC 5620", + abstract={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.}, + keywords="RFC Series Editor, Independent Stream Editor", + doi="10.17487/RFC5620", + } + +@misc{rfc5621, + author="G. Camarillo", + title="{Message Body Handling in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5621 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5621", + pages="1--19", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8262", +url="https://www.rfc-editor.org/rfc/rfc5621.txt", + key="RFC 5621", + abstract={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]}, + keywords="Message body, MIME, SIP", + doi="10.17487/RFC5621", + } + +@misc{rfc5622, + author="S. Floyd and E. Kohler", + title="{Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)}", + howpublished="RFC 5622 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5622", + pages="1--19", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6323, 8311", +url="https://www.rfc-editor.org/rfc/rfc5622.txt", + key="RFC 5622", + abstract={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.}, + keywords="ccid 4, congestion control identifier 4", + doi="10.17487/RFC5622", + } + +@misc{rfc5623, + author="E. Oki and T. Takeda and JL. Le Roux and A. Farrel", + title="{Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering}", + howpublished="RFC 5623 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5623", + pages="1--34", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5623.txt", + key="RFC 5623", + abstract={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. 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.}, + keywords="MPLS, GMPLS, Traffic Engineering, Label Switched Path, Virtual Network Topology", + doi="10.17487/RFC5623", + } + +@misc{rfc5624, + author="J. {Korhonen (Ed.)} and H. Tschofenig and E. Davies", + title="{Quality of Service Parameters for Usage with Diameter}", + howpublished="RFC 5624 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5624", + pages="1--12", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5624.txt", + key="RFC 5624", + abstract={This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter. 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]}, + keywords="Diameter, QoS Parameters", + doi="10.17487/RFC5624", + } + +@misc{rfc5625, + author="R. Bellis", + title="{DNS Proxy Implementation Guidelines}", + howpublished="RFC 5625 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5625", + pages="1--12", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5625.txt", + key="RFC 5625", + abstract={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.}, + keywords="DNS, Proxy", + doi="10.17487/RFC5625", + } + +@misc{rfc5626, + author="C. {Jennings (Ed.)} and R. {Mahy (Ed.)} and F. {Audet (Ed.)}", + title="{Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5626 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5626", + pages="1--50", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5626.txt", + key="RFC 5626", + abstract={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]}, + keywords="", + doi="10.17487/RFC5626", + } + +@misc{rfc5627, + author="J. Rosenberg", + title="{Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5627 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5627", + pages="1--40", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5627.txt", + key="RFC 5627", + abstract={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]}, + keywords="SIP, NAT, outbound, gruu, registration, traversal", + doi="10.17487/RFC5627", + } + +@misc{rfc5628, + author="P. Kyzivat", + title="{Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)}", + howpublished="RFC 5628 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5628", + pages="1--14", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5628.txt", + key="RFC 5628", + abstract={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. 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]}, + keywords="registration", + doi="10.17487/RFC5628", + } + +@misc{rfc5629, + author="J. Rosenberg", + title="{A Framework for Application Interaction in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5629 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5629", + pages="1--38", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5629.txt", + key="RFC 5629", + abstract={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]}, + keywords="sip, dtmf", + doi="10.17487/RFC5629", + } + +@misc{rfc5630, + author="F. Audet", + title="{The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5630 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5630", + pages="1--56", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5630.txt", + key="RFC 5630", + abstract={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]}, + keywords="SIPS, SIP, TLS", + doi="10.17487/RFC5630", + } + +@misc{rfc5631, + author="R. Shacham and H. Schulzrinne and S. Thakolsri and W. Kellerer", + title="{Session Initiation Protocol (SIP) Session Mobility}", + howpublished="RFC 5631 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5631", + pages="1--35", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5631.txt", + key="RFC 5631", + abstract={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.}, + keywords="third party call control (3pcc), transfer, voice over ip (voip)", + doi="10.17487/RFC5631", + } + +@misc{rfc5632, + author="C. Griffiths and J. Livingood and L. Popkin and R. Woundy and Y. Yang", + title="{Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial}", + howpublished="RFC 5632 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5632", + pages="1--12", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5632.txt", + key="RFC 5632", + abstract={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.}, + keywords="ISP, Internet Service Provider, P2P, Peer-to-Peer, P4P, Proactive Network Provider Partication for P2P, DCIA, Distributed Computing Industry Association", + doi="10.17487/RFC5632", + } + +@misc{rfc5633, + author="S. {Dawkins (Ed.)}", + title="{Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers}", + howpublished="RFC 5633 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5633", + pages="1--5", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7437", +url="https://www.rfc-editor.org/rfc/rfc5633.txt", + key="RFC 5633", + abstract={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.}, + keywords="Internet Architecture Board, Engineering Steering Group", + doi="10.17487/RFC5633", + } + +@misc{rfc5634, + author="G. Fairhurst and A. Sathiaseelan", + title="{Quick-Start for the Datagram Congestion Control Protocol (DCCP)}", + howpublished="RFC 5634 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5634", + pages="1--22", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5634.txt", + key="RFC 5634", + abstract={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 wou ld be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.}, + keywords="ccid, congestion control identifier, ccid 2, ccid 3, ccid 4", + doi="10.17487/RFC5634", + } + +@misc{rfc5635, + author="W. Kumari and D. McPherson", + title="{Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)}", + howpublished="RFC 5635 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5635", + pages="1--15", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5635.txt", + key="RFC 5635", + abstract={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.}, + keywords="rtbh", + doi="10.17487/RFC5635", + } + +@misc{rfc5636, + author="S. Park and H. Park and Y. Won and J. Lee and S. Kent", + title="{Traceable Anonymous Certificate}", + howpublished="RFC 5636 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5636", + pages="1--31", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5636.txt", + key="RFC 5636", + abstract={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.}, + keywords="x.509 certificate, blind issuer, anonymity issuer, tacs, end entity, ee", + doi="10.17487/RFC5636", + } + +@misc{rfc5637, + author="G. Giaretta and I. Guardini and E. Demaria and J. Bournelle and R. Lopez", + title="{Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6}", + howpublished="RFC 5637 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5637", + pages="1--11", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5637.txt", + key="RFC 5637", + abstract={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.}, + keywords="AAA, MIPv6, Mobile IP", + doi="10.17487/RFC5637", + } + +@misc{rfc5638, + author="H. {Sinnreich (Ed.)} and A. Johnston and E. Shim and K. Singh", + title="{Simple SIP Usage Scenario for Applications in the Endpoints}", + howpublished="RFC 5638 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5638", + pages="1--19", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5638.txt", + key="RFC 5638", + abstract={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. This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11. References for NAT traversal and for security are also provided. This memo provides information for the Internet community.}, + keywords="session initiation protocol, rich internet application, ria", + doi="10.17487/RFC5638", + } + +@misc{rfc5639, + author="M. Lochter and J. Merkle", + title="{Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation}", + howpublished="RFC 5639 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5639", + pages="1--27", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5639.txt", + key="RFC 5639", + abstract={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.}, + doi="10.17487/RFC5639", + } + +@misc{rfc5640, + author="C. Filsfils and P. Mohapatra and C. Pignataro", + title="{Load-Balancing for Mesh Softwires}", + howpublished="RFC 5640 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5640", + pages="1--6", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5640.txt", + key="RFC 5640", + abstract={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 ach ieved without such encapsulation. [STANDARDS-TRACK]}, + keywords="bgp encapsulation subsequent address family identifier, safi", + doi="10.17487/RFC5640", + } + +@misc{rfc5641, + author="N. McGill and C. Pignataro", + title="{Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values}", + howpublished="RFC 5641 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5641", + pages="1--11", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5641.txt", + key="RFC 5641", + abstract={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]}, + keywords="attachment circuits, acs, pseudowires, pw, active bit, new bit, circuit status avp", + doi="10.17487/RFC5641", + } + +@misc{rfc5642, + author="S. Venkata and S. Harwani and C. Pignataro and D. McPherson", + title="{Dynamic Hostname Exchange Mechanism for OSPF}", + howpublished="RFC 5642 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5642", + pages="1--8", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5642.txt", + key="RFC 5642", + abstract={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]}, + keywords="open shortest path first, router information, ri, ospf dynamic hostname", + doi="10.17487/RFC5642", + } + +@misc{rfc5643, + author="D. {Joyal (Ed.)} and V. {Manral (Ed.)}", + title="{Management Information Base for OSPFv3}", + howpublished="RFC 5643 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5643", + pages="1--95", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5643.txt", + key="RFC 5643", + abstract={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]}, + keywords="mib, ipv6, open shortest path first, routing protocol, OSPFV3-MIB", + doi="10.17487/RFC5643", + } + +@misc{rfc5644, + author="E. Stephan and L. Liang and A. Morton", + title="{IP Performance Metrics (IPPM): Spatial and Multicast}", + howpublished="RFC 5644 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5644", + pages="1--57", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6248", +url="https://www.rfc-editor.org/rfc/rfc5644.txt", + key="RFC 5644", + abstract={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]}, + keywords="Multiple point measurement, relative performance, group performance statistic, per hop measurement, segment performance", + doi="10.17487/RFC5644", + } + +@misc{rfc5645, + author="D. {Ewell (Ed.)}", + title="{Update to the Language Subtag Registry}", + howpublished="RFC 5645 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5645", + pages="1--13", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5645.txt", + key="RFC 5645", + abstract={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.}, + keywords="language tags, language tagging, ltru, registry", + doi="10.17487/RFC5645", + } + +@misc{rfc5646, + author="A. {Phillips (Ed.)} and M. {Davis (Ed.)}", + title="{Tags for Identifying Languages}", + howpublished="RFC 5646 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5646", + pages="1--84", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5646.txt", + key="RFC 5646", + abstract={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.}, + keywords="language tags, private interchange", + doi="10.17487/RFC5646", + } + +@misc{rfc5647, + author="K. Igoe and J. Solinas", + title="{AES Galois Counter Mode for the Secure Shell Transport Layer Protocol}", + howpublished="RFC 5647 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5647", + pages="1--10", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5647.txt", + key="RFC 5647", + abstract={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.}, + keywords="ssh, remote-login", + doi="10.17487/RFC5647", + } + +@misc{rfc5648, + author="R. {Wakikawa (Ed.)} and V. Devarapalli and G. Tsirtsis and T. Ernst and K. Nagami", + title="{Multiple Care-of Addresses Registration}", + howpublished="RFC 5648 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5648", + pages="1--36", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6089", +url="https://www.rfc-editor.org/rfc/rfc5648.txt", + key="RFC 5648", + abstract={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]}, + keywords="", + doi="10.17487/RFC5648", + } + +@misc{rfc5649, + author="R. Housley and M. Dworkin", + title="{Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm}", + howpublished="RFC 5649 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5649", + pages="1--13", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5649.txt", + key="RFC 5649", + abstract={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.}, + doi="10.17487/RFC5649", + } + +@misc{rfc5650, + author="M. Morgenstern and S. Baillie and U. Bonollo", + title="{Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)}", + howpublished="RFC 5650 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5650", + pages="1--218", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5650.txt", + key="RFC 5650", + abstract={This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing 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]}, + keywords="mib, management information base, adsl, asymmetric digital subscriber line, VDSL2-LINE-TC-MIB, VDSL2-LINE-MIB", + doi="10.17487/RFC5650", + } + +@misc{rfc5651, + author="M. Luby and M. Watson and L. Vicisano", + title="{Layered Coding Transport (LCT) Building Block}", + howpublished="RFC 5651 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5651", + pages="1--34", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5651.txt", + key="RFC 5651", + abstract={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]}, + keywords="FEC, reliable multicast", + doi="10.17487/RFC5651", + } + +@misc{rfc5652, + author="R. Housley", + title="{Cryptographic Message Syntax (CMS)}", + howpublished="RFC 5652 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5652", + pages="1--56", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5652.txt", + key="RFC 5652", + abstract={This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]}, + keywords="digital signature, message content", + doi="10.17487/RFC5652", + } + +@misc{rfc5653, + author="M. Upadhyay and S. Malkani", + title="{Generic Security Service API Version 2: Java Bindings Update}", + howpublished="RFC 5653 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5653", + pages="1--99", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8353", +url="https://www.rfc-editor.org/rfc/rfc5653.txt", + key="RFC 5653", + abstract={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. 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 Mec hanism'' (RFC 2025) and ``The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2'' (RFC 4121). [STANDARDS-TRACK]}, + keywords="gssapi, application program interface, gss-api, GSI", + doi="10.17487/RFC5653", + } + +@misc{rfc5654, + author="B. {Niven-Jenkins (Ed.)} and D. {Brungard (Ed.)} and M. {Betts (Ed.)} and N. Sprecher and S. Ueno", + title="{Requirements of an MPLS Transport Profile}", + howpublished="RFC 5654 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5654", + pages="1--31", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5654.txt", + key="RFC 5654", + abstract={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). 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. 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]}, + keywords="MPLS-TP, ITU, ITU-T", + doi="10.17487/RFC5654", + } + +@misc{rfc5655, + author="B. Trammell and E. Boschi and L. Mark and T. Zseby and A. Wagner", + title="{Specification of the IP Flow Information Export (IPFIX) File Format}", + howpublished="RFC 5655 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5655", + pages="1--64", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5655.txt", + key="RFC 5655", + abstract={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]}, + keywords="flow file, flow storage, ipfix storage, netflow storage", + doi="10.17487/RFC5655", + } + +@misc{rfc5656, + author="D. Stebila and J. Green", + title="{Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer}", + howpublished="RFC 5656 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5656", + pages="1--20", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5656.txt", + key="RFC 5656", + abstract={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]}, + keywords="Key Agreement, Cryptography", + doi="10.17487/RFC5656", + } + +@misc{rfc5657, + author="L. Dusseault and R. Sparks", + title="{Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard}", + howpublished="RFC 5657 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5657", + pages="1--12", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5657.txt", + key="RFC 5657", + abstract={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.}, + keywords="rfc2026, 2026, guidance, interoperation, implementation, reports, advancement, draft standard", + doi="10.17487/RFC5657", + } + +@misc{rfc5658, + author="T. Froment and C. Lebel and B. Bonnaerens", + title="{Addressing Record-Route Issues in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5658 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5658", + pages="1--18", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5658.txt", + key="RFC 5658", + abstract={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 th ese 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]}, + keywords="multi-homed, user agent, proxy, interoperability, double record-routing", + doi="10.17487/RFC5658", + } + +@misc{rfc5659, + author="M. Bocci and S. Bryant", + title="{An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge}", + howpublished="RFC 5659 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5659", + pages="1--24", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5659.txt", + key="RFC 5659", + abstract={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.}, + keywords="psn, packet switched network", + doi="10.17487/RFC5659", + } + +@misc{rfc5660, + author="N. Williams", + title="{IPsec Channels: Connection Latching}", + howpublished="RFC 5660 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5660", + pages="1--31", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5660.txt", + key="RFC 5660", + abstract={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. 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. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]}, + keywords="IPsec, connection latching, channel", + doi="10.17487/RFC5660", + } + +@misc{rfc5661, + author="S. {Shepler (Ed.)} and M. {Eisler (Ed.)} and D. {Noveck (Ed.)}", + title="{Network File System (NFS) Version 4 Minor Version 1 Protocol}", + howpublished="RFC 5661 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5661", + pages="1--617", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 8178, 8434", +url="https://www.rfc-editor.org/rfc/rfc5661.txt", + key="RFC 5661", + abstract={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]}, + keywords="Access Control List, ACL, Communications Sessions, Exactly Once Semantics, File Access Protocol, Global Namespace, Network Authentication, Network File Access, Network File System, Network Security, NFS, Parallel Storage, pNFS, Storage Cluster", + doi="10.17487/RFC5661", + } + +@misc{rfc5662, + author="S. {Shepler (Ed.)} and M. {Eisler (Ed.)} and D. {Noveck (Ed.)}", + title="{Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description}", + howpublished="RFC 5662 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5662", + pages="1--73", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5662.txt", + key="RFC 5662", + abstract={This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK]}, + keywords="xdr, nfsv4", + doi="10.17487/RFC5662", + } + +@misc{rfc5663, + author="D. Black and S. Fridella and J. Glasgow", + title="{Parallel NFS (pNFS) Block/Volume Layout}", + howpublished="RFC 5663 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5663", + pages="1--28", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6688", +url="https://www.rfc-editor.org/rfc/rfc5663.txt", + key="RFC 5663", + abstract={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]}, + keywords="nfsv4, network file sharing version 4", + doi="10.17487/RFC5663", + } + +@misc{rfc5664, + author="B. Halevy and B. Welch and J. Zelenka", + title="{Object-Based Parallel NFS (pNFS) Operations}", + howpublished="RFC 5664 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5664", + pages="1--35", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5664.txt", + key="RFC 5664", + abstract={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]}, + keywords="OSD, storage device", + doi="10.17487/RFC5664", + } + +@misc{rfc5665, + author="M. Eisler", + title="{IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats}", + howpublished="RFC 5665 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5665", + pages="1--14", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5665.txt", + key="RFC 5665", + abstract={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]}, + keywords="rpcbind, portmap, transport independent remote procedure call, TI-RPC, transport identifier, protocol identifier", + doi="10.17487/RFC5665", + } + +@misc{rfc5666, + author="T. Talpey and B. Callaghan", + title="{Remote Direct Memory Access Transport for Remote Procedure Call}", + howpublished="RFC 5666 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5666", + pages="1--34", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8166", +url="https://www.rfc-editor.org/rfc/rfc5666.txt", + key="RFC 5666", + abstract={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]}, + keywords="Network File System, NFS, ONC RPC, RDMA, RDDP, iWARP, InfiniBand", + doi="10.17487/RFC5666", + } + +@misc{rfc5667, + author="T. Talpey and B. Callaghan", + title="{Network File System (NFS) Direct Data Placement}", + howpublished="RFC 5667 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5667", + pages="1--10", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8267", +url="https://www.rfc-editor.org/rfc/rfc5667.txt", + key="RFC 5667", + abstract={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]}, + keywords="Network File System, NFS, ONC RPC, RDMA, RDDP, iWARP, InfiniBand", + doi="10.17487/RFC5667", + } + +@misc{rfc5668, + author="Y. Rekhter and S. Sangli and D. Tappan", + title="{4-Octet AS Specific BGP Extended Community}", + howpublished="RFC 5668 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5668", + pages="1--5", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5668.txt", + key="RFC 5668", + abstract={This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK]}, + keywords="border gateway protocol, autonomous system", + doi="10.17487/RFC5668", + } + +@misc{rfc5669, + author="S. Yoon and J. Kim and H. Park and H. Jeong and Y. Won", + title="{The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)}", + howpublished="RFC 5669 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5669", + pages="1--13", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5669.txt", + key="RFC 5669", + abstract={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]}, + keywords="", + doi="10.17487/RFC5669", + } + +@misc{rfc5670, + author="P. {Eardley (Ed.)}", + title="{Metering and Marking Behaviour of PCN-Nodes}", + howpublished="RFC 5670 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5670", + pages="1--20", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5670.txt", + key="RFC 5670", + abstract={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]}, + keywords="pre-congestion notification, threshold metering, threshold marking, pcn-threshold-rate, pcn-excess-rate", + doi="10.17487/RFC5670", + } + +@misc{rfc5671, + author="S. Yasukawa and A. {Farrel (Ed.)}", + title="{Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)}", + howpublished="RFC 5671 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5671", + pages="1--15", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5671.txt", + key="RFC 5671", + abstract={The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 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). 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.}, + keywords="multiprotocol label switching, generalized mpls", + doi="10.17487/RFC5671", + } + +@misc{rfc5672, + author="D. {Crocker (Ed.)}", + title="{RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update}", + howpublished="RFC 5672 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5672", + pages="1--14", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6376", +url="https://www.rfc-editor.org/rfc/rfc5672.txt", + key="RFC 5672", + abstract={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]}, + keywords="DKIM, email, authentication, security, spam, abuse, errata, trust, Signing Domain Identifier, SDID, AUID, Agent or User Identifier", + doi="10.17487/RFC5672", + } + +@misc{rfc5673, + author="K. {Pister (Ed.)} and P. {Thubert (Ed.)} and S. Dwars and T. Phinney", + title="{Industrial Routing Requirements in Low-Power and Lossy Networks}", + howpublished="RFC 5673 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5673", + pages="1--27", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5673.txt", + key="RFC 5673", + abstract={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.}, + keywords="lln", + doi="10.17487/RFC5673", + } + +@misc{rfc5674, + author="S. Chisholm and R. Gerhards", + title="{Alarms in Syslog}", + howpublished="RFC 5674 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5674", + pages="1--7", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5674.txt", + key="RFC 5674", + abstract={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]}, + keywords="SYSLOG, alarm", + doi="10.17487/RFC5674", + } + +@misc{rfc5675, + author="V. Marinov and J. Schoenwaelder", + title="{Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages}", + howpublished="RFC 5675 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5675", + pages="1--15", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5675.txt", + key="RFC 5675", + abstract={This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS-TRACK]}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Notifications, Syslog", + doi="10.17487/RFC5675", + } + +@misc{rfc5676, + author="J. Schoenwaelder and A. Clemm and A. Karmakar", + title="{Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications}", + howpublished="RFC 5676 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5676", + pages="1--22", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5676.txt", + key="RFC 5676", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS-TRACK]}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Notifications, Syslog", + doi="10.17487/RFC5676", + } + +@misc{rfc5677, + author="T. {Melia (Ed.)} and G. Bajko and S. Das and N. Golmie and JC. Zuniga", + title="{IEEE 802.21 Mobility Services Framework Design (MSFD)}", + howpublished="RFC 5677 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5677", + pages="1--25", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5677.txt", + key="RFC 5677", + abstract={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]}, + keywords="media independent handover, mih, mobility services, mos", + doi="10.17487/RFC5677", + } + +@misc{rfc5678, + author="G. Bajko and S. Das", + title="{Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery}", + howpublished="RFC 5678 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5678", + pages="1--14", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5678.txt", + key="RFC 5678", + abstract={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]}, + keywords="handover preparation handover decision, media independent handover services", + doi="10.17487/RFC5678", + } + +@misc{rfc5679, + author="G. Bajko", + title="{Locating IEEE 802.21 Mobility Services Using DNS}", + howpublished="RFC 5679 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5679", + pages="1--9", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5679.txt", + key="RFC 5679", + abstract={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]}, + keywords="domain name server, handover preparation, handover decision, media independent handover services", + doi="10.17487/RFC5679", + } + +@misc{rfc5680, + author="S. {Dawkins (Ed.)}", + title="{The Nominating Committee Process: Open Disclosure of Willing Nominees}", + howpublished="RFC 5680 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5680", + pages="1--7", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7437", +url="https://www.rfc-editor.org/rfc/rfc5680.txt", + key="RFC 5680", + abstract={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.}, + keywords="", + doi="10.17487/RFC5680", + } + +@misc{rfc5681, + author="M. Allman and V. Paxson and E. Blanton", + title="{TCP Congestion Control}", + howpublished="RFC 5681 (Draft Standard)", + series="Internet Request for Comments", + type="RFC", + number="5681", + pages="1--18", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5681.txt", + key="RFC 5681", + abstract={This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]}, + keywords="slow start, congestion avoidance, fast retransmit, fast recovery", + doi="10.17487/RFC5681", + } + +@misc{rfc5682, + author="P. Sarolahti and M. Kojo and K. Yamamoto and M. Hata", + title="{Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP}", + howpublished="RFC 5682 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5682", + pages="1--19", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5682.txt", + key="RFC 5682", + abstract={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. 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 effectiv ely helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]}, + keywords="SACK, transmission control protocol, loss recovery", + doi="10.17487/RFC5682", + } + +@misc{rfc5683, + author="A. Brusilovsky and I. Faynberg and Z. Zeltsan and S. Patel", + title="{Password-Authenticated Key (PAK) Diffie-Hellman Exchange}", + howpublished="RFC 5683 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5683", + pages="1--10", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5683.txt", + key="RFC 5683", + abstract={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. 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.}, + doi="10.17487/RFC5683", + } + +@misc{rfc5684, + author="P. Srisuresh and B. Ford", + title="{Unintended Consequences of NAT Deployments with Overlapping Address Space}", + howpublished="RFC 5684 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5684", + pages="1--26", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5684.txt", + key="RFC 5684", + abstract={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 information al purposes.}, + keywords="network address translator", + doi="10.17487/RFC5684", + } + +@misc{rfc5685, + author="V. Devarapalli and K. Weniger", + title="{Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 5685 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5685", + pages="1--15", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5685.txt", + key="RFC 5685", + abstract={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]}, + keywords="IKEv2 Redirect, REDIRECT, REDIRECTED\_FROM, anycast redirect, home agent redirect, VPN gateway direct", + doi="10.17487/RFC5685", + } + +@misc{rfc5686, + author="Y. Hiwasaki and H. Ohmuro", + title="{RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec}", + howpublished="RFC 5686 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5686", + pages="1--21", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5686.txt", + key="RFC 5686", + abstract={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]}, + keywords="RTP Payload type, MIME, UEMCLIP, PCMU, Speech Coding", + doi="10.17487/RFC5686", + } + +@misc{rfc5687, + author="H. Tschofenig and H. Schulzrinne", + title="{GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements}", + howpublished="RFC 5687 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5687", + pages="1--21", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5687.txt", + key="RFC 5687", + abstract={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.}, + keywords="Location Information, Location Information Server, Location by Value, Location by Reference", + doi="10.17487/RFC5687", + } + +@misc{rfc5688, + author="J. Rosenberg", + title="{A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes}", + howpublished="RFC 5688 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5688", + pages="1--7", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5688.txt", + key="RFC 5688", + abstract={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]}, + keywords="SIP, IMS", + doi="10.17487/RFC5688", + } + +@misc{rfc5689, + author="C. Daboo", + title="{Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)}", + howpublished="RFC 5689 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5689", + pages="1--12", + year=2009, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5689.txt", + key="RFC 5689", + abstract={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]}, + keywords="webdav, HTTP", + doi="10.17487/RFC5689", + } + +@misc{rfc5690, + author="S. Floyd and A. Arcia and D. Ros and J. Iyengar", + title="{Adding Acknowledgement Congestion Control to TCP}", + howpublished="RFC 5690 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5690", + pages="1--33", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5690.txt", + key="RFC 5690", + abstract={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.}, + keywords="ackcc", + doi="10.17487/RFC5690", + } + +@misc{rfc5691, + author="F. de Bont and S. Doehla and M. Schmidt and R. Sperschneider", + title="{RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio}", + howpublished="RFC 5691 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5691", + pages="1--12", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5691.txt", + key="RFC 5691", + abstract={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]}, + keywords="MPEG Surround, RFC 3640, RTP, MPEG-4, AAC", + doi="10.17487/RFC5691", + } + +@misc{rfc5692, + author="H. Jeon and S. Jeong and M. Riegel", + title="{Transmission of IP over Ethernet over IEEE 802.16 Networks}", + howpublished="RFC 5692 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5692", + pages="1--21", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5692.txt", + key="RFC 5692", + abstract={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]}, + keywords="Bridge, WiMAX, Ethernet-CS, Cellular", + doi="10.17487/RFC5692", + } + +@misc{rfc5693, + author="J. Seedorf and E. Burger", + title="{Application-Layer Traffic Optimization (ALTO) Problem Statement}", + howpublished="RFC 5693 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5693", + pages="1--14", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5693.txt", + key="RFC 5693", + abstract={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. 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.}, + keywords="peer-to-peer, p2p", + doi="10.17487/RFC5693", + } + +@misc{rfc5694, + author="G. {Camarillo (Ed.)} and IAB", + title="{Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability}", + howpublished="RFC 5694 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5694", + pages="1--26", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5694.txt", + key="RFC 5694", + abstract={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.}, + keywords="P2P, decentralized, architecture", + doi="10.17487/RFC5694", + } + +@misc{rfc5695, + author="A. Akhter and R. Asati and C. Pignataro", + title="{MPLS Forwarding Benchmarking Methodology for IP Flows}", + howpublished="RFC 5695 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5695", + pages="1--27", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5695.txt", + key="RFC 5695", + abstract={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.}, + keywords="multiprotocol label switching, mpmls forwarding devices", + doi="10.17487/RFC5695", + } + +@misc{rfc5696, + author="T. Moncaster and B. Briscoe and M. Menth", + title="{Baseline Encoding and Transport of Pre-Congestion Information}", + howpublished="RFC 5696 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5696", + pages="1--15", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6660", +url="https://www.rfc-editor.org/rfc/rfc5696.txt", + key="RFC 5696", + abstract={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]}, + keywords="Quality of Service, QoS, Differentiated Services, Admission Control, Codepoint, Protocol", + doi="10.17487/RFC5696", + } + +@misc{rfc5697, + author="S. Farrell", + title="{Other Certificates Extension}", + howpublished="RFC 5697 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5697", + pages="1--8", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5697.txt", + key="RFC 5697", + abstract={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.}, + keywords="template", + doi="10.17487/RFC5697", + } + +@misc{rfc5698, + author="T. Kunz and S. Okunick and U. Pordesch", + title="{Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)}", + howpublished="RFC 5698 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5698", + pages="1--40", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5698.txt", + key="RFC 5698", + abstract={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]}, + keywords="long term archive, security, policy, hash algorithm, public key algorithm", + doi="10.17487/RFC5698", + } + +@misc{rfc5701, + author="Y. Rekhter", + title="{IPv6 Address Specific BGP Extended Community Attribute}", + howpublished="RFC 5701 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5701", + pages="1--5", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7153, 7606", +url="https://www.rfc-editor.org/rfc/rfc5701.txt", + key="RFC 5701", + abstract={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]}, + keywords="border gateway protocol", + doi="10.17487/RFC5701", + } + +@misc{rfc5702, + author="J. Jansen", + title="{Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC}", + howpublished="RFC 5702 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5702", + pages="1--10", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6944", +url="https://www.rfc-editor.org/rfc/rfc5702.txt", + key="RFC 5702", + abstract={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]}, + keywords="DNSSEC, RSA, SHA-256, SHA-512", + doi="10.17487/RFC5702", + } + +@misc{rfc5703, + author="T. Hansen and C. Daboo", + title="{Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure}", + howpublished="RFC 5703 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5703", + pages="1--18", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5703.txt", + key="RFC 5703", + abstract={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]}, + keywords="Email, Electronic Mail, Internet Mail, Message Filtering", + doi="10.17487/RFC5703", + } + +@misc{rfc5704, + author="S. {Bryant (Ed.)} and M. {Morrow (Ed.)} and IAB", + title="{Uncoordinated Protocol Development Considered Harmful}", + howpublished="RFC 5704 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5704", + pages="1--15", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5704.txt", + key="RFC 5704", + abstract={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. 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. Whilst we u se 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.}, + keywords="ITU-T, MPLS-TP, T-MPLS, Joint working team, JWT", + doi="10.17487/RFC5704", + } + +@misc{rfc5705, + author="E. Rescorla", + title="{Keying Material Exporters for Transport Layer Security (TLS)}", + howpublished="RFC 5705 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5705", + pages="1--7", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 8446, 8447", +url="https://www.rfc-editor.org/rfc/rfc5705.txt", + key="RFC 5705", + abstract={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]}, + keywords="key establishment", + doi="10.17487/RFC5705", + } + +@misc{rfc5706, + author="D. Harrington", + title="{Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions}", + howpublished="RFC 5706 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5706", + pages="1--35", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5706.txt", + key="RFC 5706", + abstract={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.}, + keywords="management, operations", + doi="10.17487/RFC5706", + } + +@misc{rfc5707, + author="A. Saleem and Y. Xin and G. Sharratt", + title="{Media Server Markup Language (MSML)}", + howpublished="RFC 5707 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5707", + pages="1--184", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5707.txt", + key="RFC 5707", + abstract={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 dia logs 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.}, + doi="10.17487/RFC5707", + } + +@misc{rfc5708, + author="A. Keromytis", + title="{X.509 Key and Signature Encoding for the KeyNote Trust Management System}", + howpublished="RFC 5708 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5708", + pages="1--6", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5708.txt", + key="RFC 5708", + abstract={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. 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.}, + doi="10.17487/RFC5708", + } + +@misc{rfc5709, + author="M. Bhatia and V. Manral and M. Fanto and R. White and M. Barnes and T. Li and R. Atkinson", + title="{OSPFv2 HMAC-SHA Cryptographic Authentication}", + howpublished="RFC 5709 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5709", + pages="1--14", + year=2009, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7474", +url="https://www.rfc-editor.org/rfc/rfc5709.txt", + key="RFC 5709", + abstract={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]}, + keywords="open shortest path first, nist, secure hash standard, hashed message authentication code", + doi="10.17487/RFC5709", + } + +@misc{rfc5710, + author="L. Berger and D. Papadimitriou and JP. Vasseur", + title="{PathErr Message Triggered MPLS and GMPLS LSP Reroutes}", + howpublished="RFC 5710 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5710", + pages="1--12", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5710.txt", + key="RFC 5710", + abstract={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]}, + keywords="resource reservation protocol, rsvp, multiprotocol label switching, generalized mpls, rsvp-te", + doi="10.17487/RFC5710", + } + +@misc{rfc5711, + author="JP. {Vasseur (Ed.)} and G. Swallow and I. Minei", + title="{Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages}", + howpublished="RFC 5711 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5711", + pages="1--7", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5711.txt", + key="RFC 5711", + abstract={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]}, + keywords="rsvp-te", + doi="10.17487/RFC5711", + } + +@misc{rfc5712, + author="M. {Meyer (Ed.)} and JP. {Vasseur (Ed.)}", + title="{MPLS Traffic Engineering Soft Preemption}", + howpublished="RFC 5712 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5712", + pages="1--13", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5712.txt", + key="RFC 5712", + abstract={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]}, + keywords="multiprotocol label switching, mpls-te, te lsp", + doi="10.17487/RFC5712", + } + +@misc{rfc5713, + author="H. Moustafa and H. Tschofenig and S. De Cnodder", + title="{Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)}", + howpublished="RFC 5713 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5713", + pages="1--18", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5713.txt", + key="RFC 5713", + abstract={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. 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.}, + keywords="ANCP security, ANCP threats, ANCP attacks", + doi="10.17487/RFC5713", + } + +@misc{rfc5714, + author="M. Shand and S. Bryant", + title="{IP Fast Reroute Framework}", + howpublished="RFC 5714 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5714", + pages="1--15", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5714.txt", + key="RFC 5714", + abstract={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.}, + keywords="IP Fast Reroute, MPLS Fast Reroute, Routing Convergence, Network Topology, loop-free-convergence", + doi="10.17487/RFC5714", + } + +@misc{rfc5715, + author="M. Shand and S. Bryant", + title="{A Framework for Loop-Free Convergence}", + howpublished="RFC 5715 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5715", + pages="1--22", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5715.txt", + key="RFC 5715", + abstract={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. 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.}, + keywords="IP Fast Reroute, MPLS Fast Reroute, Routing Convergence, Network Topology, PLSN, not-via, Incremental Cost, Packet Marking, ordered fib, ofib", + doi="10.17487/RFC5715", + } + +@misc{rfc5716, + author="J. Lentini and C. Everhart and D. Ellard and R. Tewari and M. Naik", + title="{Requirements for Federated File Systems}", + howpublished="RFC 5716 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5716", + pages="1--26", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5716.txt", + key="RFC 5716", + abstract={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.}, + keywords="Federated File Systems, Federated FA, FedFS, Fed-FS, Federation", + doi="10.17487/RFC5716", + } + +@misc{rfc5717, + author="B. Lengyel and M. Bjorklund", + title="{Partial Lock Remote Procedure Call (RPC) for NETCONF}", + howpublished="RFC 5717 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5717", + pages="1--23", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5717.txt", + key="RFC 5717", + abstract={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]}, + keywords="YANG, Network Management", + doi="10.17487/RFC5717", + } + +@misc{rfc5718, + author="D. Beller and A. Farrel", + title="{An In-Band Data Communication Network For the MPLS Transport Profile}", + howpublished="RFC 5718 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5718", + pages="1--8", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5718.txt", + key="RFC 5718", + abstract={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. 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. 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 d elivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]}, + keywords="MPLS-TP, DCN, SCN, MCN, G-Ach, GAL", + doi="10.17487/RFC5718", + } + +@misc{rfc5719, + author="D. Romascanu and H. Tschofenig", + title="{Updated IANA Considerations for Diameter Command Code Allocations}", + howpublished="RFC 5719 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5719", + pages="1--5", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6733", +url="https://www.rfc-editor.org/rfc/rfc5719.txt", + key="RFC 5719", + abstract={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. This docu ment 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]}, + keywords="diameter application, diameter commands", + doi="10.17487/RFC5719", + } + +@misc{rfc5720, + author="F. Templin", + title="{Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)}", + howpublished="RFC 5720 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5720", + pages="1--26", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5720.txt", + key="RFC 5720", + abstract={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 pub lished for informational purposes.}, + keywords="enterprise network", + doi="10.17487/RFC5720", + } + +@misc{rfc5721, + author="R. Gellens and C. Newman", + title="{POP3 Support for UTF-8}", + howpublished="RFC 5721 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5721", + pages="1--13", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6856", +url="https://www.rfc-editor.org/rfc/rfc5721.txt", + key="RFC 5721", + abstract={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.}, + keywords="POP, UTF8, mail, email, internationalization, charset", + doi="10.17487/RFC5721", + } + +@misc{rfc5722, + author="S. Krishnan", + title="{Handling of Overlapping IPv6 Fragments}", + howpublished="RFC 5722 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5722", + pages="1--6", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6946", +url="https://www.rfc-editor.org/rfc/rfc5722.txt", + key="RFC 5722", + abstract={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]}, + keywords="fragmentation, overlapping fragments", + doi="10.17487/RFC5722", + } + +@misc{rfc5723, + author="Y. Sheffer and H. Tschofenig", + title="{Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption}", + howpublished="RFC 5723 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5723", + pages="1--26", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5723.txt", + key="RFC 5723", + abstract={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. 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. 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 m anner, utilizing a previously established IKE SA. 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]}, + keywords="IKE, Internet Key Exchange, session resumption, failover, high availability, cryptographic ticket, cryptographic token, stateful resumption, stateless resumption", + doi="10.17487/RFC5723", + } + +@misc{rfc5724, + author="E. Wilde and A. Vaha-Sipila", + title="{URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)}", + howpublished="RFC 5724 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5724", + pages="1--18", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5724.txt", + key="RFC 5724", + abstract={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]}, + keywords="GSM, SMS, URI scheme", + doi="10.17487/RFC5724", + } + +@misc{rfc5725, + author="A. Begen and D. Hsu and M. Lague", + title="{Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)}", + howpublished="RFC 5725 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5725", + pages="1--9", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5725.txt", + key="RFC 5725", + abstract={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]}, + keywords="Loss repair, retransmission, FEC", + doi="10.17487/RFC5725", + } + +@misc{rfc5726, + author="Y. Qiu and F. {Zhao (Ed.)} and R. Koodli", + title="{Mobile IPv6 Location Privacy Solutions}", + howpublished="RFC 5726 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5726", + pages="1--48", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5726.txt", + key="RFC 5726", + abstract={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.}, + keywords="mobopts", + doi="10.17487/RFC5726", + } + +@misc{rfc5727, + author="J. Peterson and C. Jennings and R. Sparks", + title="{Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area}", + howpublished="RFC 5727 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5727", + pages="1--14", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7957", +url="https://www.rfc-editor.org/rfc/rfc5727.txt", + key="RFC 5727", + abstract={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.}, + keywords="RAI, sipping", + doi="10.17487/RFC5727", + } + +@misc{rfc5728, + author="S. Combes and P. Amundsen and M. Lambert and H-P. Lexow", + title="{The SatLabs Group DVB-RCS MIB}", + howpublished="RFC 5728 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5728", + pages="1--95", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5728.txt", + key="RFC 5728", + abstract={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.}, + keywords="management information base, digital video broadcasting return channel, DVB-RCS-MIB", + doi="10.17487/RFC5728", + } + +@misc{rfc5729, + author="J. {Korhonen (Ed.)} and M. Jones and L. Morand and T. Tsou", + title="{Clarifications on the Routing of Diameter Requests Based on the Username and the Realm}", + howpublished="RFC 5729 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5729", + pages="1--11", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5729.txt", + key="RFC 5729", + abstract={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]}, + keywords="nai, network access identifier, decorated, multi-realm", + doi="10.17487/RFC5729", + } + +@misc{rfc5730, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 5730 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5730", + pages="1--67", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5730.txt", + key="RFC 5730", + abstract={This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]}, + keywords="shared framework mapping", + doi="10.17487/RFC5730", + } + +@misc{rfc5731, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Domain Name Mapping}", + howpublished="RFC 5731 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5731", + pages="1--44", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5731.txt", + key="RFC 5731", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]}, + keywords="EPP, Extensible Provisioning Protocol, XML, domain, domain name", + doi="10.17487/RFC5731", + } + +@misc{rfc5732, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Host Mapping}", + howpublished="RFC 5732 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5732", + pages="1--29", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5732.txt", + key="RFC 5732", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]}, + keywords="EPP, Extensible Provisioning Protocol, XML, host", + doi="10.17487/RFC5732", + } + +@misc{rfc5733, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Contact Mapping}", + howpublished="RFC 5733 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5733", + pages="1--41", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5733.txt", + key="RFC 5733", + abstract={This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ``contacts'') stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]}, + keywords="EPP, Extensible Provisioning Protocol, XML, contact, registrant", + doi="10.17487/RFC5733", + } + +@misc{rfc5734, + author="S. Hollenbeck", + title="{Extensible Provisioning Protocol (EPP) Transport over TCP}", + howpublished="RFC 5734 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="5734", + pages="1--13", + year=2009, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5734.txt", + key="RFC 5734", + abstract={This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]}, + keywords="EPP, Extensible Provisioning Protocol, XML, TCP, TLS", + doi="10.17487/RFC5734", + } + +@misc{rfc5735, + author="M. Cotton and L. Vegoda", + title="{Special Use IPv4 Addresses}", + howpublished="RFC 5735 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5735", + pages="1--10", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6890, updated by RFC 6598", +url="https://www.rfc-editor.org/rfc/rfc5735.txt", + key="RFC 5735", + abstract={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.}, + keywords="internet protocol, space assignments", + doi="10.17487/RFC5735", + } + +@misc{rfc5736, + author="G. Huston and M. Cotton and L. Vegoda", + title="{IANA IPv4 Special Purpose Address Registry}", + howpublished="RFC 5736 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5736", + pages="1--6", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6890", +url="https://www.rfc-editor.org/rfc/rfc5736.txt", + key="RFC 5736", + abstract={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.}, + doi="10.17487/RFC5736", + } + +@misc{rfc5737, + author="J. Arkko and M. Cotton and L. Vegoda", + title="{IPv4 Address Blocks Reserved for Documentation}", + howpublished="RFC 5737 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5737", + pages="1--4", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5737.txt", + key="RFC 5737", + abstract={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.}, + keywords="example addresses, IPv4", + doi="10.17487/RFC5737", + } + +@misc{rfc5738, + author="P. Resnick and C. Newman", + title="{IMAP Support for UTF-8}", + howpublished="RFC 5738 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5738", + pages="1--15", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6855", +url="https://www.rfc-editor.org/rfc/rfc5738.txt", + key="RFC 5738", + abstract={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.}, + keywords="internet message access protocol, imap4rev1", + doi="10.17487/RFC5738", + } + +@misc{rfc5739, + author="P. Eronen and J. Laganier and C. Madson", + title="{IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 5739 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5739", + pages="1--32", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5739.txt", + key="RFC 5739", + abstract={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.}, + keywords="remote vpn access, vpn gateway, virtual link", + doi="10.17487/RFC5739", + } + +@misc{rfc5740, + author="B. Adamson and C. Bormann and M. Handley and J. Macker", + title="{NACK-Oriented Reliable Multicast (NORM) Transport Protocol}", + howpublished="RFC 5740 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5740", + pages="1--96", + year=2009, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5740.txt", + key="RFC 5740", + abstract={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 hi gher-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]}, + keywords="multicast, reliable multicast, transport, negative-acknowledgment, forward error correction, packet erasure coding, group communication", + doi="10.17487/RFC5740", + } + +@misc{rfc5741, + author="L. {Daigle (Ed.)} and O. {Kolkman (Ed.)} and IAB", + title="{RFC Streams, Headers, and Boilerplates}", + howpublished="RFC 5741 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5741", + pages="1--16", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7841", +url="https://www.rfc-editor.org/rfc/rfc5741.txt", + key="RFC 5741", + abstract={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.}, + doi="10.17487/RFC5741", + } + +@misc{rfc5742, + author="H. Alvestrand and R. Housley", + title="{IESG Procedures for Handling of Independent and IRTF Stream Submissions}", + howpublished="RFC 5742 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5742", + pages="1--9", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5742.txt", + key="RFC 5742", + abstract={This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.}, + keywords="", + doi="10.17487/RFC5742", + } + +@misc{rfc5743, + author="A. Falk", + title="{Definition of an Internet Research Task Force (IRTF) Document Stream}", + howpublished="RFC 5743 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5743", + pages="1--9", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5743.txt", + key="RFC 5743", + abstract={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.}, + keywords="irtf stream", + doi="10.17487/RFC5743", + } + +@misc{rfc5744, + author="R. Braden and J. Halpern", + title="{Procedures for Rights Handling in the RFC Independent Submission Stream}", + howpublished="RFC 5744 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5744", + pages="1--6", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5744.txt", + key="RFC 5744", + abstract={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.}, + keywords="incoming rights, outgoing rights, ietf trust", + doi="10.17487/RFC5744", + } + +@misc{rfc5745, + author="A. {Malis (Ed.)} and IAB", + title="{Procedures for Rights Handling in the RFC IAB Stream}", + howpublished="RFC 5745 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5745", + pages="1--6", + year=2009, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5745.txt", + key="RFC 5745", + abstract={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.}, + keywords="incoming rights, outgoing rights, ietf trust", + doi="10.17487/RFC5745", + } + +@misc{rfc5746, + author="E. Rescorla and M. Ray and S. Dispensa and N. Oskov", + title="{Transport Layer Security (TLS) Renegotiation Indication Extension}", + howpublished="RFC 5746 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5746", + pages="1--15", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5746.txt", + key="RFC 5746", + abstract={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]}, + keywords="ssl, secure socket layer", + doi="10.17487/RFC5746", + } + +@misc{rfc5747, + author="J. Wu and Y. Cui and X. Li and M. Xu and C. Metz", + title="{4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions}", + howpublished="RFC 5747 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5747", + pages="1--15", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5747.txt", + key="RFC 5747", + abstract={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.}, + keywords="IPv4/IPv6, coexistence, CNGI, CERNET2, Softwire mesh", + doi="10.17487/RFC5747", + } + +@misc{rfc5748, + author="S. Yoon and J. Jeong and H. Kim and H. Jeong and Y. Won", + title="{IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)}", + howpublished="RFC 5748 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5748", + pages="1--5", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5748.txt", + key="RFC 5748", + abstract={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.}, + doi="10.17487/RFC5748", + } + +@misc{rfc5749, + author="K. {Hoeper (Ed.)} and M. Nakhjiri and Y. {Ohba (Ed.)}", + title="{Distribution of EAP-Based Keys for Handover and Re-Authentication}", + howpublished="RFC 5749 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5749", + pages="1--12", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5749.txt", + key="RFC 5749", + abstract={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]}, + keywords="security, authentication, mobility, EAP, key management, key distribution", + doi="10.17487/RFC5749", + } + +@misc{rfc5750, + author="B. Ramsdell and S. Turner", + title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling}", + howpublished="RFC 5750 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5750", + pages="1--21", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5750.txt", + key="RFC 5750", + abstract={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]}, + keywords="encryption, certificate, multipurpose, internet, mail , extensions, secure", + doi="10.17487/RFC5750", + } + +@misc{rfc5751, + author="B. Ramsdell and S. Turner", + title="{Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification}", + howpublished="RFC 5751 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5751", + pages="1--45", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5751.txt", + key="RFC 5751", + abstract={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]}, + keywords="secure, multipurpose, internet, mail, extensions, encryption", + doi="10.17487/RFC5751", + } + +@misc{rfc5752, + author="S. Turner and J. Schaad", + title="{Multiple Signatures in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 5752 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5752", + pages="1--17", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5752.txt", + key="RFC 5752", + abstract={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]}, + keywords="signeddata, signerinfo, downgrade attacks, algorithm migration", + doi="10.17487/RFC5752", + } + +@misc{rfc5753, + author="S. Turner and D. Brown", + title="{Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)}", + howpublished="RFC 5753 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5753", + pages="1--61", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5753.txt", + key="RFC 5753", + abstract={This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the 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.}, + keywords="public key, digital signatures, authentication", + doi="10.17487/RFC5753", + } + +@misc{rfc5754, + author="S. Turner", + title="{Using SHA2 Algorithms with Cryptographic Message Syntax}", + howpublished="RFC 5754 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5754", + pages="1--10", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5754.txt", + key="RFC 5754", + abstract={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]}, + keywords="secure hash algorithm, message digest algorithm, sha-224, sha-256, sha-384, sha-512, cms, dsa, digital signature algorithm, rsa, rivest sharmi adleman, ecdsa, elliptic curve dsa, smimecapabilities", + doi="10.17487/RFC5754", + } + +@misc{rfc5755, + author="S. Farrell and R. Housley and S. Turner", + title="{An Internet Attribute Certificate Profile for Authorization}", + howpublished="RFC 5755 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5755", + pages="1--50", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5755.txt", + key="RFC 5755", + abstract={This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]}, + keywords="electronic mail, email, ipsec, www security", + doi="10.17487/RFC5755", + } + +@misc{rfc5756, + author="S. Turner and D. Brown and K. Yiu and R. Housley and T. Polk", + title="{Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters}", + howpublished="RFC 5756 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5756", + pages="1--6", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5756.txt", + key="RFC 5756", + abstract={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]}, + keywords="rsa encryption scheme, optical asymmetric encryption padding, subjectpublickeyinfo", + doi="10.17487/RFC5756", + } + +@misc{rfc5757, + author="T. Schmidt and M. Waehlisch and G. Fairhurst", + title="{Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey}", + howpublished="RFC 5757 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5757", + pages="1--37", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5757.txt", + key="RFC 5757", + abstract={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 specificati on; it is published for informational purposes.}, + keywords="PMIPv6, FMIPv6, HMIPv6, SSM, ASM, MLD, Mobile Multicast Routing, Hybrid Multicast, Wireless, Multipoint", + doi="10.17487/RFC5757", + } + +@misc{rfc5758, + author="Q. Dang and S. Santesson and K. Moriarty and D. Brown and T. Polk", + title="{Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA}", + howpublished="RFC 5758 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5758", + pages="1--8", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5758.txt", + key="RFC 5758", + abstract={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]}, + keywords="digital signature algorithm, elliptic curve digital signature algorithm, pki", + doi="10.17487/RFC5758", + } + +@misc{rfc5759, + author="J. Solinas and L. Zieglar", + title="{Suite B Certificate and Certificate Revocation List (CRL) Profile}", + howpublished="RFC 5759 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5759", + pages="1--11", + year=2010, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5759.txt", + key="RFC 5759", + abstract={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.}, + keywords="x.509 v3 certificates, x.509 v2 certificate revocation lists, crl", + doi="10.17487/RFC5759", + } + +@misc{rfc5760, + author="J. Ott and J. Chesterfield and E. Schooler", + title="{RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback}", + howpublished="RFC 5760 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5760", + pages="1--66", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6128", +url="https://www.rfc-editor.org/rfc/rfc5760.txt", + key="RFC 5760", + abstract={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]}, + keywords="real-time transport protocol, ssm", + doi="10.17487/RFC5760", + } + +@misc{rfc5761, + author="C. Perkins and M. Westerlund", + title="{Multiplexing RTP Data and Control Packets on a Single Port}", + howpublished="RFC 5761 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5761", + pages="1--13", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8035", +url="https://www.rfc-editor.org/rfc/rfc5761.txt", + key="RFC 5761", + abstract={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]}, + keywords="", + doi="10.17487/RFC5761", + } + +@misc{rfc5762, + author="C. Perkins", + title="{RTP and the Datagram Congestion Control Protocol (DCCP)}", + howpublished="RFC 5762 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5762", + pages="1--16", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6773", +url="https://www.rfc-editor.org/rfc/rfc5762.txt", + key="RFC 5762", + abstract={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]}, + keywords="real-time transport protocol", + doi="10.17487/RFC5762", + } + +@misc{rfc5763, + author="J. Fischl and H. Tschofenig and E. Rescorla", + title="{Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 5763 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5763", + pages="1--37", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5763.txt", + key="RFC 5763", + abstract={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]}, + keywords="stip, session initiation protocol, fingerprint attribute, dtls handshake", + doi="10.17487/RFC5763", + } + +@misc{rfc5764, + author="D. McGrew and E. Rescorla", + title="{Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)}", + howpublished="RFC 5764 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5764", + pages="1--26", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7983", +url="https://www.rfc-editor.org/rfc/rfc5764.txt", + key="RFC 5764", + abstract={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]}, + keywords="secure rtp control protocol, srtcp", + doi="10.17487/RFC5764", + } + +@misc{rfc5765, + author="H. Schulzrinne and E. Marocco and E. Ivov", + title="{Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications}", + howpublished="RFC 5765 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5765", + pages="1--28", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5765.txt", + key="RFC 5765", + abstract={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.}, + keywords="p2p, overlay, rtc, voip", + doi="10.17487/RFC5765", + } + +@misc{rfc5766, + author="R. Mahy and P. Matthews and J. Rosenberg", + title="{Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)}", + howpublished="RFC 5766 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5766", + pages="1--67", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8155", +url="https://www.rfc-editor.org/rfc/rfc5766.txt", + key="RFC 5766", + abstract={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]}, + keywords="NAT, TURN, STUN, ICE", + doi="10.17487/RFC5766", + } + +@misc{rfc5767, + author="M. Munakata and S. Schubert and T. Ohba", + title="{User-Agent-Driven Privacy Mechanism for SIP}", + howpublished="RFC 5767 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5767", + pages="1--11", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5767.txt", + key="RFC 5767", + abstract={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.}, + keywords="SIP, IMS, privacy, guidelines", + doi="10.17487/RFC5767", + } + +@misc{rfc5768, + author="J. Rosenberg", + title="{Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5768 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5768", + pages="1--6", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5768.txt", + key="RFC 5768", + abstract={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]}, + keywords="SIP, NAT", + doi="10.17487/RFC5768", + } + +@misc{rfc5769, + author="R. Denis-Courmont", + title="{Test Vectors for Session Traversal Utilities for NAT (STUN)}", + howpublished="RFC 5769 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5769", + pages="1--11", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5769.txt", + key="RFC 5769", + abstract={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.}, + keywords="STUN, test, vectors, fingerprint", + doi="10.17487/RFC5769", + } + +@misc{rfc5770, + author="M. Komu and T. Henderson and H. Tschofenig and J. Melen and A. {Keranen (Ed.)}", + title="{Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators}", + howpublished="RFC 5770 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5770", + pages="1--34", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5770.txt", + key="RFC 5770", + abstract={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.}, + keywords="ICE, HIP relay", + doi="10.17487/RFC5770", + } + +@misc{rfc5771, + author="M. Cotton and L. Vegoda and D. Meyer", + title="{IANA Guidelines for IPv4 Multicast Address Assignments}", + howpublished="RFC 5771 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5771", + pages="1--11", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5771.txt", + key="RFC 5771", + abstract={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.}, + keywords="internet, assigned, numbers, authority, protocol, parameters", + doi="10.17487/RFC5771", + } + +@misc{rfc5772, + author="A. Doria and E. Davies and F. Kastenholz", + title="{A Set of Possible Requirements for a Future Routing Architecture}", + howpublished="RFC 5772 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5772", + pages="1--68", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5772.txt", + key="RFC 5772", + abstract={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. 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.}, + keywords="Routing Research Group, RRG, IDR, FDR", + doi="10.17487/RFC5772", + } + +@misc{rfc5773, + author="E. Davies and A. Doria", + title="{Analysis of Inter-Domain Routing Requirements and History}", + howpublished="RFC 5773 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5773", + pages="1--51", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5773.txt", + key="RFC 5773", + abstract={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 necessa rily 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.}, + keywords="History, IRTF, Routing Research Group, RRG, Routing Requirements, IDR, FDR", + doi="10.17487/RFC5773", + } + +@misc{rfc5774, + author="K. Wolf and A. Mayrhofer", + title="{Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition}", + howpublished="RFC 5774 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5774", + pages="1--33", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5774.txt", + key="RFC 5774", + abstract={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.}, + keywords="", + doi="10.17487/RFC5774", + } + +@misc{rfc5775, + author="M. Luby and M. Watson and L. Vicisano", + title="{Asynchronous Layered Coding (ALC) Protocol Instantiation}", + howpublished="RFC 5775 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5775", + pages="1--24", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5775.txt", + key="RFC 5775", + abstract={This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. [STANDARDS-TRACK]}, + keywords="Forward Error Correction, FEC, Layered Coding Transport, LCT, Building Block, WEBRC, reliable +object delivery, reliable file delivery, broadcast, multicast", + doi="10.17487/RFC5775", + } + +@misc{rfc5776, + author="V. Roca and A. Francillon and S. Faurite", + title="{Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols}", + howpublished="RFC 5776 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5776", + pages="1--58", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5776.txt", + key="RFC 5776", + abstract={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.}, + keywords="TESLA, FLUTE, ALC, NORM", + doi="10.17487/RFC5776", + } + +@misc{rfc5777, + author="J. Korhonen and H. Tschofenig and M. Arumaithurai and M. {Jones (Ed.)} and A. Lior", + title="{Traffic Classification and Quality of Service (QoS) Attributes for Diameter}", + howpublished="RFC 5777 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5777", + pages="1--43", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5777.txt", + key="RFC 5777", + abstract={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]}, + keywords="Diameter, Qos Attributes, Traffic classification, Filtering, Firewalling", + doi="10.17487/RFC5777", + } + +@misc{rfc5778, + author="J. {Korhonen (Ed.)} and H. Tschofenig and J. Bournelle and G. Giaretta and M. Nakhjiri", + title="{Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction}", + howpublished="RFC 5778 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5778", + pages="1--34", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5778.txt", + key="RFC 5778", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC5778", + } + +@misc{rfc5779, + author="J. {Korhonen (Ed.)} and J. Bournelle and K. Chowdhury and A. Muhanna and U. Meyer", + title="{Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server}", + howpublished="RFC 5779 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5779", + pages="1--20", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5779.txt", + key="RFC 5779", + abstract={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]}, + keywords="aaa, authentication, authorization, and accounting", + doi="10.17487/RFC5779", + } + +@misc{rfc5780, + author="D. MacDonald and B. Lowekamp", + title="{NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)}", + howpublished="RFC 5780 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5780", + pages="1--27", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5780.txt", + key="RFC 5780", + abstract={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.}, + keywords="NAT type diagnostics", + doi="10.17487/RFC5780", + } + +@misc{rfc5781, + author="S. Weiler and D. Ward and R. Housley", + title="{The rsync URI Scheme}", + howpublished="RFC 5781 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5781", + pages="1--4", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5781.txt", + key="RFC 5781", + abstract={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.}, + keywords="rsyncuri", + doi="10.17487/RFC5781", + } + +@misc{rfc5782, + author="J. Levine", + title="{DNS Blacklists and Whitelists}", + howpublished="RFC 5782 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5782", + pages="1--11", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5782.txt", + key="RFC 5782", + abstract={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.}, + keywords="mail, electronic mail, DNS, spam, blacklist, whitelist", + doi="10.17487/RFC5782", + } + +@misc{rfc5783, + author="M. Welzl and W. Eddy", + title="{Congestion Control in the RFC Series}", + howpublished="RFC 5783 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5783", + pages="1--28", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5783.txt", + key="RFC 5783", + abstract={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.}, + doi="10.17487/RFC5783", + } + +@misc{rfc5784, + author="N. Freed and S. Vedam", + title="{Sieve Email Filtering: Sieves and Display Directives in XML}", + howpublished="RFC 5784 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5784", + pages="1--32", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5784.txt", + key="RFC 5784", + abstract={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. 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]}, + keywords="SMTP, ESMTP, Sieve", + doi="10.17487/RFC5784", + } + +@misc{rfc5785, + author="M. Nottingham and E. Hammer-Lahav", + title="{Defining Well-Known Uniform Resource Identifiers (URIs)}", + howpublished="RFC 5785 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5785", + pages="1--8", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5785.txt", + key="RFC 5785", + abstract={This memo defines a path prefix for ``well-known locations'', ``/.well-known/'', in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]}, + keywords="well-known locations", + doi="10.17487/RFC5785", + } + +@misc{rfc5786, + author="R. Aggarwal and K. Kompella", + title="{Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions}", + howpublished="RFC 5786 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5786", + pages="1--7", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6827", +url="https://www.rfc-editor.org/rfc/rfc5786.txt", + key="RFC 5786", + abstract={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. 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. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5786", + } + +@misc{rfc5787, + author="D. Papadimitriou", + title="{OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing}", + howpublished="RFC 5787 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5787", + pages="1--29", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6827", +url="https://www.rfc-editor.org/rfc/rfc5787.txt", + key="RFC 5787", + abstract={The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). 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. 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. 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 Recommend ations are revised or if new requirements are introduced into a revision of RFC 4258. This document defines an Experimental Protocol for the Internet community.}, + keywords="itu-t, ospfv2 link state routing protocol", + doi="10.17487/RFC5787", + } + +@misc{rfc5788, + author="A. Melnikov and D. Cridland", + title="{IMAP4 Keyword Registry}", + howpublished="RFC 5788 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5788", + pages="1--11", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5788.txt", + key="RFC 5788", + abstract={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]}, + keywords="IMAP, email, tag, label, keyword", + doi="10.17487/RFC5788", + } + +@misc{rfc5789, + author="L. Dusseault and J. Snell", + title="{PATCH Method for HTTP}", + howpublished="RFC 5789 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5789", + pages="1--10", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5789.txt", + key="RFC 5789", + abstract={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]}, + keywords="HTTP, PATCH, Hypertext Transfer Protocol", + doi="10.17487/RFC5789", + } + +@misc{rfc5790, + author="H. Liu and W. Cao and H. Asaeda", + title="{Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols}", + howpublished="RFC 5790 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5790", + pages="1--17", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5790.txt", + key="RFC 5790", + abstract={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]}, + keywords="IGMP, MLD, Lite, lightweight", + doi="10.17487/RFC5790", + } + +@misc{rfc5791, + author="J. Reschke and J. Kunze", + title="{RFC 2731 (``Encoding Dublin Core Metadata in HTML'') Is Obsolete}", + howpublished="RFC 5791 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5791", + pages="1--2", + year=2010, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5791.txt", + key="RFC 5791", + abstract={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.}, + keywords="DCMI, Dublin Core Metadata Initiative, XHTML, HTML, metadata", + doi="10.17487/RFC5791", + } + +@misc{rfc5792, + author="P. Sangster and K. Narayan", + title="{PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)}", + howpublished="RFC 5792 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5792", + pages="1--83", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5792.txt", + key="RFC 5792", + abstract={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]}, + keywords="", + doi="10.17487/RFC5792", + } + +@misc{rfc5793, + author="R. Sahita and S. Hanna and R. Hurst and K. Narayan", + title="{PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)}", + howpublished="RFC 5793 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5793", + pages="1--76", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5793.txt", + key="RFC 5793", + abstract={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]}, + keywords="NEA, Network Endpoint Assessment", + doi="10.17487/RFC5793", + } + +@misc{rfc5794, + author="J. Lee and J. Lee and J. Kim and D. Kwon and C. Kim", + title="{A Description of the ARIA Encryption Algorithm}", + howpublished="RFC 5794 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5794", + pages="1--18", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5794.txt", + key="RFC 5794", + abstract={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.}, + keywords="ARIA, encryption, block, cipher", + doi="10.17487/RFC5794", + } + +@misc{rfc5795, + author="K. Sandlund and G. Pelletier and L-E. Jonsson", + title="{The RObust Header Compression (ROHC) Framework}", + howpublished="RFC 5795 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5795", + pages="1--41", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5795.txt", + key="RFC 5795", + abstract={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. 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. This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5795", + } + +@misc{rfc5796, + author="W. Atwood and S. Islam and M. Siami", + title="{Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages}", + howpublished="RFC 5796 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5796", + pages="1--21", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5796.txt", + key="RFC 5796", + abstract={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]}, + keywords="security, PIM-SM, routing security, multicast routing, link-local message, Protocol Independent Multicast Sparse Mode", + doi="10.17487/RFC5796", + } + +@misc{rfc5797, + author="J. Klensin and A. Hoenes", + title="{FTP Command and Extension Registry}", + howpublished="RFC 5797 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5797", + pages="1--10", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5797.txt", + key="RFC 5797", + abstract={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]}, + keywords="FTP FEAT command, FTP FEAT response", + doi="10.17487/RFC5797", + } + +@misc{rfc5798, + author="S. {Nadas (Ed.)}", + title="{Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6}", + howpublished="RFC 5798 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5798", + pages="1--40", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5798.txt", + key="RFC 5798", + abstract={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 t he 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]}, + keywords="", + doi="10.17487/RFC5798", + } + +@misc{rfc5801, + author="S. Josefsson and N. Williams", + title="{Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family}", + howpublished="RFC 5801 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5801", + pages="1--26", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5801.txt", + key="RFC 5801", + abstract={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]}, + keywords="", + doi="10.17487/RFC5801", + } + +@misc{rfc5802, + author="C. Newman and A. Menon-Sen and A. Melnikov and N. Williams", + title="{Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms}", + howpublished="RFC 5802 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5802", + pages="1--28", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7677", +url="https://www.rfc-editor.org/rfc/rfc5802.txt", + key="RFC 5802", + abstract={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. 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 prot ocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]}, + keywords="simple authentication and security layer", + doi="10.17487/RFC5802", + } + +@misc{rfc5803, + author="A. Melnikov", + title="{Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets}", + howpublished="RFC 5803 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5803", + pages="1--4", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5803.txt", + key="RFC 5803", + abstract={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.}, + keywords="authpassword, simple authentication and security layer, sasl", + doi="10.17487/RFC5803", + } + +@misc{rfc5804, + author="A. {Melnikov (Ed.)} and T. Martin", + title="{A Protocol for Remotely Managing Sieve Scripts}", + howpublished="RFC 5804 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5804", + pages="1--49", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7817", +url="https://www.rfc-editor.org/rfc/rfc5804.txt", + key="RFC 5804", + abstract={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]}, + keywords="managesieve", + doi="10.17487/RFC5804", + } + +@misc{rfc5805, + author="K. Zeilenga", + title="{Lightweight Directory Access Protocol (LDAP) Transactions}", + howpublished="RFC 5805 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5805", + pages="1--11", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5805.txt", + key="RFC 5805", + abstract={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.}, + keywords="acid, atomic consistency isolation durability", + doi="10.17487/RFC5805", + } + +@misc{rfc5806, + author="S. Levy and M. {Mohali (Ed.)}", + title="{Diversion Indication in SIP}", + howpublished="RFC 5806 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5806", + pages="1--53", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5806.txt", + key="RFC 5806", + abstract={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. 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. 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 .}, + doi="10.17487/RFC5806", + } + +@misc{rfc5807, + author="Y. Ohba and A. Yegin", + title="{Definition of Master Key between PANA Client and Enforcement Point}", + howpublished="RFC 5807 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5807", + pages="1--7", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5807.txt", + key="RFC 5807", + abstract={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]}, + keywords="protocol for carrying authentication for network access", + doi="10.17487/RFC5807", + } + +@misc{rfc5808, + author="R. {Marshall (Ed.)}", + title="{Requirements for a Location-by-Reference Mechanism}", + howpublished="RFC 5808 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5808", + pages="1--14", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5808.txt", + key="RFC 5808", + abstract={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.}, + doi="10.17487/RFC5808", + } + +@misc{rfc5810, + author="A. {Doria (Ed.)} and J. Hadi {Salim (Ed.)} and R. {Haas (Ed.)} and H. {Khosravi (Ed.)} and W. {Wang (Ed.)} and L. Dong and R. Gopal and J. Halpern", + title="{Forwarding and Control Element Separation (ForCES) Protocol Specification}", + howpublished="RFC 5810 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5810", + pages="1--124", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7121, 7391", +url="https://www.rfc-editor.org/rfc/rfc5810.txt", + key="RFC 5810", + abstract={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]}, + keywords="control elements, forwarding elements, fe, ce, network element, ne, tml, transport mapping layer", + doi="10.17487/RFC5810", + } + +@misc{rfc5811, + author="J. Hadi Salim and K. Ogawa", + title="{SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol}", + howpublished="RFC 5811 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5811", + pages="1--28", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5811.txt", + key="RFC 5811", + abstract={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]}, + keywords="ForCES, TML, stream conrol transmission protocol", + doi="10.17487/RFC5811", + } + +@misc{rfc5812, + author="J. Halpern and J. Hadi Salim", + title="{Forwarding and Control Element Separation (ForCES) Forwarding Element Model}", + howpublished="RFC 5812 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5812", + pages="1--134", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7408", +url="https://www.rfc-editor.org/rfc/rfc5812.txt", + key="RFC 5812", + abstract={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]}, + keywords="forwarding element, control element", + doi="10.17487/RFC5812", + } + +@misc{rfc5813, + author="R. Haas", + title="{Forwarding and Control Element Separation (ForCES) MIB}", + howpublished="RFC 5813 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5813", + pages="1--17", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5813.txt", + key="RFC 5813", + abstract={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]}, + keywords="management information base, network element, ne, forces-mib", + doi="10.17487/RFC5813", + } + +@misc{rfc5814, + author="W. {Sun (Ed.)} and G. {Zhang (Ed.)}", + title="{Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks}", + howpublished="RFC 5814 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5814", + pages="1--44", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5814.txt", + key="RFC 5814", + abstract={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. This document provides a series of performance metrics to evalua te 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]}, + keywords="Signaling performance, RSVP-TE delay measurement, control plane performance", + doi="10.17487/RFC5814", + } + +@misc{rfc5815, + author="T. {Dietz (Ed.)} and A. Kobayashi and B. Claise and G. Muenz", + title="{Definitions of Managed Objects for IP Flow Information Export}", + howpublished="RFC 5815 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5815", + pages="1--64", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6615", +url="https://www.rfc-editor.org/rfc/rfc5815.txt", + key="RFC 5815", + abstract={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]}, + keywords="Selector, Collector, Exporter, Sampling, Filtering, IPFIX, IPFIX-MIB, IPFIX-SELECTOR-MIB", + doi="10.17487/RFC5815", + } + +@misc{rfc5816, + author="S. Santesson and N. Pope", + title="{ESSCertIDv2 Update for RFC 3161}", + howpublished="RFC 5816 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5816", + pages="1--5", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5816.txt", + key="RFC 5816", + abstract={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]}, + keywords="signer certificate, secure hash algorithm, sha-1", + doi="10.17487/RFC5816", + } + +@misc{rfc5817, + author="Z. Ali and JP. Vasseur and A. Zamfir and J. Newton", + title="{Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks}", + howpublished="RFC 5817 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5817", + pages="1--11", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5817.txt", + key="RFC 5817", + abstract={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. 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.}, + keywords="mpls-te, te", + doi="10.17487/RFC5817", + } + +@misc{rfc5818, + author="D. Li and H. Xu and S. Bardalai and J. Meuric and D. Caviglia", + title="{Data Channel Status Confirmation Extensions for the Link Management Protocol}", + howpublished="RFC 5818 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5818", + pages="1--15", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6898", +url="https://www.rfc-editor.org/rfc/rfc5818.txt", + key="RFC 5818", + abstract={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]}, + keywords="LMP", + doi="10.17487/RFC5818", + } + +@misc{rfc5819, + author="A. Melnikov and T. Sirainen", + title="{IMAP4 Extension for Returning STATUS Information in Extended LIST}", + howpublished="RFC 5819 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5819", + pages="1--6", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5819.txt", + key="RFC 5819", + abstract={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]}, + keywords="list, lsub", + doi="10.17487/RFC5819", + } + +@misc{rfc5820, + author="A. {Roy (Ed.)} and M. {Chandra (Ed.)}", + title="{Extensions to OSPF to Support Mobile Ad Hoc Networking}", + howpublished="RFC 5820 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5820", + pages="1--41", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7137", +url="https://www.rfc-editor.org/rfc/rfc5820.txt", + key="RFC 5820", + abstract={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]}, + keywords="open shortest path first, manet, ospf-or, ospf-overlapping relay, link-local signaling, lls, ospf-manet", + doi="10.17487/RFC5820", + } + +@misc{rfc5824, + author="K. {Kumaki (Ed.)} and R. Zhang and Y. Kamite", + title="{Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN}", + howpublished="RFC 5824 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5824", + pages="1--27", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5824.txt", + key="RFC 5824", + abstract={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. 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.}, + keywords="triple-play service", + doi="10.17487/RFC5824", + } + +@misc{rfc5825, + author="K. Fujiwara and B. Leiba", + title="{Displaying Downgraded Messages for Email Address Internationalization}", + howpublished="RFC 5825 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5825", + pages="1--14", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6530", +url="https://www.rfc-editor.org/rfc/rfc5825.txt", + key="RFC 5825", + abstract={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.}, + keywords="EAI, Email Address Internationalization, Downgrade, MAIL", + doi="10.17487/RFC5825", + } + +@misc{rfc5826, + author="A. Brandt and J. Buron and G. Porcu", + title="{Home Automation Routing Requirements in Low-Power and Lossy Networks}", + howpublished="RFC 5826 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5826", + pages="1--17", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5826.txt", + key="RFC 5826", + abstract={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.}, + keywords="roll, routing over low power and lossy", + doi="10.17487/RFC5826", + } + +@misc{rfc5827, + author="M. Allman and K. Avrachenkov and U. Ayesta and J. Blanton and P. Hurtig", + title="{Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)}", + howpublished="RFC 5827 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5827", + pages="1--15", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5827.txt", + key="RFC 5827", + abstract={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]}, + keywords="transmission control protocol, fast retransmission", + doi="10.17487/RFC5827", + } + +@misc{rfc5828, + author="D. Fedyk and L. Berger and L. Andersson", + title="{Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework}", + howpublished="RFC 5828 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5828", + pages="1--20", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5828.txt", + key="RFC 5828", + abstract={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.}, + keywords="transport networks", + doi="10.17487/RFC5828", + } + +@misc{rfc5829, + author="A. Brown and G. Clemm and J. {Reschke (Ed.)}", + title="{Link Relation Types for Simple Version Navigation between Web Resources}", + howpublished="RFC 5829 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5829", + pages="1--12", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5829.txt", + key="RFC 5829", + abstract={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.}, + doi="10.17487/RFC5829", + } + +@misc{rfc5830, + author="V. {Dolmatov (Ed.)}", + title="{GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms}", + howpublished="RFC 5830 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5830", + pages="1--19", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5830.txt", + key="RFC 5830", + abstract={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.}, + keywords="russian federal standard, electronic encryption, decryption, message authentication, russian cryptographic standard", + doi="10.17487/RFC5830", + } + +@misc{rfc5831, + author="V. {Dolmatov (Ed.)}", + title="{GOST R 34.11-94: Hash Function Algorithm}", + howpublished="RFC 5831 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5831", + pages="1--17", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6986", +url="https://www.rfc-editor.org/rfc/rfc5831.txt", + key="RFC 5831", + abstract={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.}, + keywords="russian federal standard, russian cryptographic standard, russian cryptography", + doi="10.17487/RFC5831", + } + +@misc{rfc5832, + author="V. {Dolmatov (Ed.)}", + title="{GOST R 34.10-2001: Digital Signature Algorithm}", + howpublished="RFC 5832 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5832", + pages="1--22", + year=2010, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7091", +url="https://www.rfc-editor.org/rfc/rfc5832.txt", + key="RFC 5832", + abstract={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.}, + keywords="russian federal standard, digital signature, russian cryptographic standard, russian cryptography", + doi="10.17487/RFC5832", + } + +@misc{rfc5833, + author="Y. {Shi (Ed.)} and D. {Perkins (Ed.)} and C. {Elliott (Ed.)} and Y. {Zhang (Ed.)}", + title="{Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB}", + howpublished="RFC 5833 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5833", + pages="1--73", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5833.txt", + key="RFC 5833", + abstract={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.}, + keywords="mib, CAPWAP-BASE-MIB", + doi="10.17487/RFC5833", + } + +@misc{rfc5834, + author="Y. {Shi (Ed.)} and D. {Perkins (Ed.)} and C. {Elliott (Ed.)} and Y. {Zhang (Ed.)}", + title="{Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11}", + howpublished="RFC 5834 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5834", + pages="1--25", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5834.txt", + key="RFC 5834", + abstract={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.}, + keywords="mib, CAPWAP-DOT11-MIB", + doi="10.17487/RFC5834", + } + +@misc{rfc5835, + author="A. {Morton (Ed.)} and S. Van den {Berghe (Ed.)}", + title="{Framework for Metric Composition}", + howpublished="RFC 5835 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5835", + pages="1--18", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5835.txt", + key="RFC 5835", + abstract={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.}, + doi="10.17487/RFC5835", + } + +@misc{rfc5836, + author="Y. {Ohba (Ed.)} and Q. {Wu (Ed.)} and G. {Zorn (Ed.)}", + title="{Extensible Authentication Protocol (EAP) Early Authentication Problem Statement}", + howpublished="RFC 5836 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5836", + pages="1--20", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5836.txt", + key="RFC 5836", + abstract={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.}, + keywords="eap early authentication", + doi="10.17487/RFC5836", + } + +@misc{rfc5837, + author="A. {Atlas (Ed.)} and R. {Bonica (Ed.)} and C. {Pignataro (Ed.)} and N. Shen and JR. Rivers", + title="{Extending ICMP for Interface and Next-Hop Identification}", + howpublished="RFC 5837 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5837", + pages="1--18", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5837.txt", + key="RFC 5837", + abstract={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. 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]}, + keywords="Internet Control Message Protocol", + doi="10.17487/RFC5837", + } + +@misc{rfc5838, + author="A. {Lindem (Ed.)} and S. Mirtorabi and A. Roy and M. Barnes and R. Aggarwal", + title="{Support of Address Families in OSPFv3}", + howpublished="RFC 5838 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5838", + pages="1--13", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6969, 7949, 8362", +url="https://www.rfc-editor.org/rfc/rfc5838.txt", + key="RFC 5838", + abstract={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]}, + keywords="af, instance id", + doi="10.17487/RFC5838", + } + +@misc{rfc5839, + author="A. Niemi and D. {Willis (Ed.)}", + title="{An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification}", + howpublished="RFC 5839 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5839", + pages="1--25", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5839.txt", + key="RFC 5839", + abstract={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]}, + keywords="SIP events, subnot-etags, optimization", + doi="10.17487/RFC5839", + } + +@misc{rfc5840, + author="K. Grewal and G. Montenegro and M. Bhatia", + title="{Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility}", + howpublished="RFC 5840 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5840", + pages="1--15", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5840.txt", + key="RFC 5840", + abstract={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]}, + keywords="wesp", + doi="10.17487/RFC5840", + } + +@misc{rfc5841, + author="R. Hay and W. Turkal", + title="{TCP Option to Denote Packet Mood}", + howpublished="RFC 5841 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5841", + pages="1--9", + year=2010, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5841.txt", + key="RFC 5841", + abstract={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.}, + doi="10.17487/RFC5841", + } + +@misc{rfc5842, + author="G. Clemm and J. Crawford and J. {Reschke (Ed.)} and J. Whitehead", + title="{Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)}", + howpublished="RFC 5842 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5842", + pages="1--45", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5842.txt", + key="RFC 5842", + abstract={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.}, + keywords="HTTP, WebDAV, collections, hard link", + doi="10.17487/RFC5842", + } + +@misc{rfc5843, + author="A. Bryan", + title="{Additional Hash Algorithms for HTTP Instance Digests}", + howpublished="RFC 5843 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5843", + pages="1--5", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5843.txt", + key="RFC 5843", + abstract={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.}, + keywords="Hypertext Transfer Protocol, HTTP, Digest Algorithm Values registry update", + doi="10.17487/RFC5843", + } + +@misc{rfc5844, + author="R. Wakikawa and S. Gundavelli", + title="{IPv4 Support for Proxy Mobile IPv6}", + howpublished="RFC 5844 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5844", + pages="1--49", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5844.txt", + key="RFC 5844", + abstract={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]}, + keywords="NAT traversal, Dual Stack, Mobility, IPv4 Support, IPv4 Support for PMIPv6", + doi="10.17487/RFC5844", + } + +@misc{rfc5845, + author="A. Muhanna and M. Khalil and S. Gundavelli and K. Leung", + title="{Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6}", + howpublished="RFC 5845 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5845", + pages="1--25", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5845.txt", + key="RFC 5845", + abstract={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]}, + keywords="PMIP6, PMIPv6, Downlink GRE Key, Uplink GRE Key, TLV-Header Tunneling, TLV-Header Tunneling, GRE Key Exchange", + doi="10.17487/RFC5845", + } + +@misc{rfc5846, + author="A. Muhanna and M. Khalil and S. Gundavelli and K. Chowdhury and P. Yegani", + title="{Binding Revocation for IPv6 Mobility}", + howpublished="RFC 5846 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5846", + pages="1--39", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5846.txt", + key="RFC 5846", + abstract={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]}, + keywords="PMIP6, PMIPv6, Binding Revocation Indication, BRI, Binding Revocation Acknowledgement, BRA, MIP6, DSMIP6, Multiple Care-of Addresses, PMIPv6 Revocation, Bulk PMIPv6 Revocation", + doi="10.17487/RFC5846", + } + +@misc{rfc5847, + author="V. {Devarapalli (Ed.)} and R. {Koodli (Ed.)} and H. Lim and N. Kant and S. Krishnan and J. Laganier", + title="{Heartbeat Mechanism for Proxy Mobile IPv6}", + howpublished="RFC 5847 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5847", + pages="1--11", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5847.txt", + key="RFC 5847", + abstract={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]}, + keywords="Node Reachability, Restarts, Failure Detection", + doi="10.17487/RFC5847", + } + +@misc{rfc5848, + author="J. Kelsey and J. Callas and A. Clemm", + title="{Signed Syslog Messages}", + howpublished="RFC 5848 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5848", + pages="1--40", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5848.txt", + key="RFC 5848", + abstract={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]}, + keywords="syslog, syslog-sign", + doi="10.17487/RFC5848", + } + +@misc{rfc5849, + author="E. {Hammer-Lahav (Ed.)}", + title="{The OAuth 1.0 Protocol}", + howpublished="RFC 5849 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5849", + pages="1--38", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6749", +url="https://www.rfc-editor.org/rfc/rfc5849.txt", + key="RFC 5849", + abstract={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.}, + keywords="authorization, delegation", + doi="10.17487/RFC5849", + } + +@misc{rfc5850, + author="R. Mahy and R. Sparks and J. Rosenberg and D. Petrie and A. {Johnston (Ed.)}", + title="{A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)}", + howpublished="RFC 5850 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5850", + pages="1--44", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5850.txt", + key="RFC 5850", + abstract={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 specific ation; it is published for informational purposes.}, + keywords="call control, multiparty, features, mixing, refer, 3pcc, Refer method, Replaces header field, Join header field, conferencing", + doi="10.17487/RFC5850", + } + +@misc{rfc5851, + author="S. Ooghe and N. Voigt and M. Platnic and T. Haag and S. Wadhwa", + title="{Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks}", + howpublished="RFC 5851 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5851", + pages="1--47", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5851.txt", + key="RFC 5851", + abstract={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. 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 n etwork 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.}, + keywords="Access Node Control Protocol, Topology Discovery, Loop Configuration, Remote Connectivity Test, Multicast, Access Node, Network Access Server", + doi="10.17487/RFC5851", + } + +@misc{rfc5852, + author="D. Caviglia and D. Ceccarelli and D. Bramanti and D. Li and S. Bardalai", + title="{RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network}", + howpublished="RFC 5852 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5852", + pages="1--23", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5852.txt", + key="RFC 5852", + abstract={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. 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 ext ension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]}, + keywords="resource reservation protocol, handover procedures", + doi="10.17487/RFC5852", + } + +@misc{rfc5853, + author="J. {Hautakorpi (Ed.)} and G. Camarillo and R. Penfield and A. Hawrylyshen and M. Bhatia", + title="{Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments}", + howpublished="RFC 5853 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5853", + pages="1--26", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5853.txt", + key="RFC 5853", + abstract={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.}, + doi="10.17487/RFC5853", + } + +@misc{rfc5854, + author="A. Bryan and T. Tsujikawa and N. McNab and P. Poeml", + title="{The Metalink Download Description Format}", + howpublished="RFC 5854 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5854", + pages="1--39", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5854.txt", + key="RFC 5854", + abstract={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]}, + keywords="file transfer, mirrors, data integrity, hash, xml, http, hypertext transfer protocol, ftp, file transfer protocol, metadata, torrent", + doi="10.17487/RFC5854", + } + +@misc{rfc5855, + author="J. Abley and T. Manderson", + title="{Nameservers for IPv4 and IPv6 Reverse Zones}", + howpublished="RFC 5855 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="5855", + pages="1--12", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5855.txt", + key="RFC 5855", + abstract={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.}, + keywords=" IN-ADDR.ARPA, IP6.ARPA, reverse mapping", + doi="10.17487/RFC5855", + } + +@misc{rfc5856, + author="E. Ertekin and R. Jasani and C. Christou and C. Bormann", + title="{Integration of Robust Header Compression over IPsec Security Associations}", + howpublished="RFC 5856 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5856", + pages="1--15", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5856.txt", + key="RFC 5856", + abstract={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.}, + keywords="ROHC, ROHCoIPsec", + doi="10.17487/RFC5856", + } + +@misc{rfc5857, + author="E. Ertekin and C. Christou and R. Jasani and T. Kivinen and C. Bormann", + title="{IKEv2 Extensions to Support Robust Header Compression over IPsec}", + howpublished="RFC 5857 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5857", + pages="1--13", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5857.txt", + key="RFC 5857", + abstract={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]}, + keywords="ROHC, ROHCoIPsec", + doi="10.17487/RFC5857", + } + +@misc{rfc5858, + author="E. Ertekin and C. Christou and C. Bormann", + title="{IPsec Extensions to Support Robust Header Compression over IPsec}", + howpublished="RFC 5858 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5858", + pages="1--15", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5858.txt", + key="RFC 5858", + abstract={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]}, + keywords="ROHC, ROHCoIPsec", + doi="10.17487/RFC5858", + } + +@misc{rfc5859, + author="R. Johnson", + title="{TFTP Server Address Option for DHCPv4}", + howpublished="RFC 5859 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5859", + pages="1--6", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5859.txt", + key="RFC 5859", + abstract={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.}, + keywords="voip", + doi="10.17487/RFC5859", + } + +@misc{rfc5860, + author="M. {Vigoureux (Ed.)} and D. {Ward (Ed.)} and M. {Betts (Ed.)}", + title="{Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks}", + howpublished="RFC 5860 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5860", + pages="1--17", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5860.txt", + key="RFC 5860", + abstract={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]}, + keywords="MPLS-TP, OAM", + doi="10.17487/RFC5860", + } + +@misc{rfc5861, + author="M. Nottingham", + title="{HTTP Cache-Control Extensions for Stale Content}", + howpublished="RFC 5861 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5861", + pages="1--6", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5861.txt", + key="RFC 5861", + abstract={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.}, + doi="10.17487/RFC5861", + } + +@misc{rfc5862, + author="S. Yasukawa and A. Farrel", + title="{Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE}", + howpublished="RFC 5862 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5862", + pages="1--11", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5862.txt", + key="RFC 5862", + abstract={The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 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. 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.}, + keywords="mpls, gmpls", + doi="10.17487/RFC5862", + } + +@misc{rfc5863, + author="T. Hansen and E. Siegel and P. Hallam-Baker and D. Crocker", + title="{DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations}", + howpublished="RFC 5863 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5863", + pages="1--51", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5863.txt", + key="RFC 5863", + abstract={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.}, + keywords="Email, Electronic Mail, Internet Mail, Message Verification", + doi="10.17487/RFC5863", + } + +@misc{rfc5864, + author="R. Allbery", + title="{DNS SRV Resource Records for AFS}", + howpublished="RFC 5864 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5864", + pages="1--10", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5864.txt", + key="RFC 5864", + abstract={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]}, + keywords="domain name system, srv rr, distributed file system, afsdb rr", + doi="10.17487/RFC5864", + } + +@misc{rfc5865, + author="F. Baker and J. Polk and M. Dolly", + title="{A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic}", + howpublished="RFC 5865 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5865", + pages="1--14", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5865.txt", + key="RFC 5865", + abstract={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]}, + keywords="real-time traffic", + doi="10.17487/RFC5865", + } + +@misc{rfc5866, + author="D. {Sun (Ed.)} and P. McCann and H. Tschofenig and T. Tsou and A. Doria and G. {Zorn (Ed.)}", + title="{Diameter Quality-of-Service Application}", + howpublished="RFC 5866 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5866", + pages="1--51", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5866.txt", + key="RFC 5866", + abstract={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]}, + keywords="Diameter, AAA, QoS, Policy, VoIP, SIP", + doi="10.17487/RFC5866", + } + +@misc{rfc5867, + author="J. {Martocci (Ed.)} and P. De Mil and N. Riou and W. Vermeylen", + title="{Building Automation Routing Requirements in Low-Power and Lossy Networks}", + howpublished="RFC 5867 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5867", + pages="1--26", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5867.txt", + key="RFC 5867", + abstract={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.}, + doi="10.17487/RFC5867", + } + +@misc{rfc5868, + author="S. Sakane and K. Kamada and S. Zrelli and M. Ishiyama", + title="{Problem Statement on the Cross-Realm Operation of Kerberos}", + howpublished="RFC 5868 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5868", + pages="1--13", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5868.txt", + key="RFC 5868", + abstract={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. 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.}, + doi="10.17487/RFC5868", + } + +@misc{rfc5869, + author="H. Krawczyk and P. Eronen", + title="{HMAC-based Extract-and-Expand Key Derivation Function (HKDF)}", + howpublished="RFC 5869 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5869", + pages="1--14", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5869.txt", + key="RFC 5869", + abstract={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.}, + doi="10.17487/RFC5869", + } + +@misc{rfc5870, + author="A. Mayrhofer and C. Spanring", + title="{A Uniform Resource Identifier for Geographic Locations ('geo' URI)}", + howpublished="RFC 5870 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5870", + pages="1--23", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5870.txt", + key="RFC 5870", + abstract={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]}, + keywords="geography, geo, uri, scheme", + doi="10.17487/RFC5870", + } + +@misc{rfc5871, + author="J. Arkko and S. Bradner", + title="{IANA Allocation Guidelines for the IPv6 Routing Header}", + howpublished="RFC 5871 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5871", + pages="1--3", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5871.txt", + key="RFC 5871", + abstract={This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]}, + keywords="routing type field", + doi="10.17487/RFC5871", + } + +@misc{rfc5872, + author="J. Arkko and A. Yegin", + title="{IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)}", + howpublished="RFC 5872 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5872", + pages="1--5", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5872.txt", + key="RFC 5872", + abstract={This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5872", + } + +@misc{rfc5873, + author="Y. Ohba and A. Yegin", + title="{Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)}", + howpublished="RFC 5873 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5873", + pages="1--8", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5873.txt", + key="RFC 5873", + abstract={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.}, + keywords="", + doi="10.17487/RFC5873", + } + +@misc{rfc5874, + author="J. Rosenberg and J. Urpalainen", + title="{An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources}", + howpublished="RFC 5874 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5874", + pages="1--24", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5874.txt", + key="RFC 5874", + abstract={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]}, + keywords="SIP, Instant Messaging", + doi="10.17487/RFC5874", + } + +@misc{rfc5875, + author="J. Urpalainen and D. {Willis (Ed.)}", + title="{An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package}", + howpublished="RFC 5875 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5875", + pages="1--27", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5875.txt", + key="RFC 5875", + abstract={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]}, + keywords="xcap-diff, xcap diff", + doi="10.17487/RFC5875", + } + +@misc{rfc5876, + author="J. Elwell", + title="{Updates to Asserted Identity in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5876 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5876", + pages="1--11", + year=2010, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5876.txt", + key="RFC 5876", + abstract={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.}, + keywords="SIP, P-Asserted-Identity", + doi="10.17487/RFC5876", + } + +@misc{rfc5877, + author="R. Housley", + title="{The application/pkix-attr-cert Media Type for Attribute Certificates}", + howpublished="RFC 5877 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5877", + pages="1--4", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5877.txt", + key="RFC 5877", + abstract={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.}, + doi="10.17487/RFC5877", + } + +@misc{rfc5878, + author="M. Brown and R. Housley", + title="{Transport Layer Security (TLS) Authorization Extensions}", + howpublished="RFC 5878 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5878", + pages="1--19", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8447", +url="https://www.rfc-editor.org/rfc/rfc5878.txt", + key="RFC 5878", + abstract={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.}, + keywords="handshake protocol", + doi="10.17487/RFC5878", + } + +@misc{rfc5879, + author="T. Kivinen and D. McDonald", + title="{Heuristics for Detecting ESP-NULL Packets}", + howpublished="RFC 5879 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5879", + pages="1--32", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5879.txt", + key="RFC 5879", + abstract={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.}, + keywords="IPsec, Wrapped ESP (WESP), deep-inspection, packet inspection", + doi="10.17487/RFC5879", + } + +@misc{rfc5880, + author="D. Katz and D. Ward", + title="{Bidirectional Forwarding Detection (BFD)}", + howpublished="RFC 5880 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5880", + pages="1--49", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7419, 7880", +url="https://www.rfc-editor.org/rfc/rfc5880.txt", + key="RFC 5880", + abstract={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]}, + keywords="", + doi="10.17487/RFC5880", + } + +@misc{rfc5881, + author="D. Katz and D. Ward", + title="{Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)}", + howpublished="RFC 5881 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5881", + pages="1--7", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5881.txt", + key="RFC 5881", + abstract={This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5881", + } + +@misc{rfc5882, + author="D. Katz and D. Ward", + title="{Generic Application of Bidirectional Forwarding Detection (BFD)}", + howpublished="RFC 5882 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5882", + pages="1--17", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5882.txt", + key="RFC 5882", + abstract={This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5882", + } + +@misc{rfc5883, + author="D. Katz and D. Ward", + title="{Bidirectional Forwarding Detection (BFD) for Multihop Paths}", + howpublished="RFC 5883 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5883", + pages="1--6", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5883.txt", + key="RFC 5883", + abstract={This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5883", + } + +@misc{rfc5884, + author="R. Aggarwal and K. Kompella and T. Nadeau and G. Swallow", + title="{Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)}", + howpublished="RFC 5884 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5884", + pages="1--12", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7726", +url="https://www.rfc-editor.org/rfc/rfc5884.txt", + key="RFC 5884", + abstract={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]}, + keywords="Multiprotocol Label Switching, lsp ping", + doi="10.17487/RFC5884", + } + +@misc{rfc5885, + author="T. {Nadeau (Ed.)} and C. {Pignataro (Ed.)}", + title="{Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)}", + howpublished="RFC 5885 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5885", + pages="1--14", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6478, 7885", +url="https://www.rfc-editor.org/rfc/rfc5885.txt", + key="RFC 5885", + abstract={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]}, + keywords="Pseudowire, VCCV, BFD, VCCV-BFD, PW OAM", + doi="10.17487/RFC5885", + } + +@misc{rfc5886, + author="JP. {Vasseur (Ed.)} and JL. Le Roux and Y. Ikejiri", + title="{A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture}", + howpublished="RFC 5886 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5886", + pages="1--26", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5886.txt", + key="RFC 5886", + abstract={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''. 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 o f 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]}, + doi="10.17487/RFC5886", + } + +@misc{rfc5887, + author="B. Carpenter and R. Atkinson and H. Flinck", + title="{Renumbering Still Needs Work}", + howpublished="RFC 5887 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5887", + pages="1--35", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5887.txt", + key="RFC 5887", + abstract={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.}, + doi="10.17487/RFC5887", + } + +@misc{rfc5888, + author="G. Camarillo and H. Schulzrinne", + title="{The Session Description Protocol (SDP) Grouping Framework}", + howpublished="RFC 5888 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5888", + pages="1--21", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5888.txt", + key="RFC 5888", + abstract={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]}, + keywords="SDP, grouping, SIP", + doi="10.17487/RFC5888", + } + +@misc{rfc5889, + author="E. {Baccelli (Ed.)} and M. {Townsley (Ed.)}", + title="{IP Addressing Model in Ad Hoc Networks}", + howpublished="RFC 5889 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5889", + pages="1--8", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5889.txt", + key="RFC 5889", + abstract={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.}, + keywords="mobile network, ad hoc network, MANET, network architecture, addressing framework, configuration, routing, IP networks", + doi="10.17487/RFC5889", + } + +@misc{rfc5890, + author="J. Klensin", + title="{Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework}", + howpublished="RFC 5890 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5890", + pages="1--23", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5890.txt", + key="RFC 5890", + abstract={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]}, + keywords="IDNA2008, idn, ascii, characters", + doi="10.17487/RFC5890", + } + +@misc{rfc5891, + author="J. Klensin", + title="{Internationalized Domain Names in Applications (IDNA): Protocol}", + howpublished="RFC 5891 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5891", + pages="1--17", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5891.txt", + key="RFC 5891", + abstract={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]}, + keywords="IDNA2008, idn, ascii, characters, idna applications", + doi="10.17487/RFC5891", + } + +@misc{rfc5892, + author="P. {Faltstrom (Ed.)}", + title="{The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)}", + howpublished="RFC 5892 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5892", + pages="1--70", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5892.txt", + key="RFC 5892", + abstract={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). It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]}, + keywords="IDNA, DNS, IDN, Unicode, IDNA2008", + doi="10.17487/RFC5892", + } + +@misc{rfc5893, + author="H. {Alvestrand (Ed.)} and C. Karp", + title="{Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)}", + howpublished="RFC 5893 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5893", + pages="1--17", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5893.txt", + key="RFC 5893", + abstract={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]}, + keywords="IDNA2008, idn, ascii, characters, Bidi", + doi="10.17487/RFC5893", + } + +@misc{rfc5894, + author="J. Klensin", + title="{Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale}", + howpublished="RFC 5894 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5894", + pages="1--43", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5894.txt", + key="RFC 5894", + abstract={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.}, + keywords="IDNA2008, idn, ascii, characters", + doi="10.17487/RFC5894", + } + +@misc{rfc5895, + author="P. Resnick and P. Hoffman", + title="{Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008}", + howpublished="RFC 5895 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5895", + pages="1--7", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5895.txt", + key="RFC 5895", + abstract={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.}, + keywords="user input, character mapping, locale, user interface, Unicode", + doi="10.17487/RFC5895", + } + +@misc{rfc5896, + author="L. Hornquist Astrand and S. Hartman", + title="{Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy}", + howpublished="RFC 5896 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5896", + pages="1--6", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5896.txt", + key="RFC 5896", + abstract={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]}, + keywords="", + doi="10.17487/RFC5896", + } + +@misc{rfc5897, + author="J. Rosenberg", + title="{Identification of Communications Services in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5897 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5897", + pages="1--23", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5897.txt", + key="RFC 5897", + abstract={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.}, + keywords="service identification", + doi="10.17487/RFC5897", + } + +@misc{rfc5898, + author="F. Andreasen and G. Camarillo and D. Oran and D. Wing", + title="{Connectivity Preconditions for Session Description Protocol (SDP) Media Streams}", + howpublished="RFC 5898 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5898", + pages="1--17", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5898.txt", + key="RFC 5898", + abstract={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]}, + keywords="SIP, preconditions, connection, connectivity", + doi="10.17487/RFC5898", + } + +@misc{rfc5901, + author="P. Cain and D. Jevans", + title="{Extensions to the IODEF-Document Class for Reporting Phishing}", + howpublished="RFC 5901 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5901", + pages="1--51", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5901.txt", + key="RFC 5901", + abstract={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]}, + keywords="Incident Object Description Exchange Format", + doi="10.17487/RFC5901", + } + +@misc{rfc5902, + author="D. Thaler and L. Zhang and G. Lebovitz", + title="{IAB Thoughts on IPv6 Network Address Translation}", + howpublished="RFC 5902 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5902", + pages="1--15", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5902.txt", + key="RFC 5902", + abstract={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.}, + keywords="NAT, IPv6, Transparency, End-to-End, Privacy, Multihoming", + doi="10.17487/RFC5902", + } + +@misc{rfc5903, + author="D. Fu and J. Solinas", + title="{Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2}", + howpublished="RFC 5903 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5903", + pages="1--16", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5903.txt", + key="RFC 5903", + abstract={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.}, + keywords="Elliptic Curve Cryptography, ECC, Internet Key Exchange, elliptic curve, Diffie-Hellman, suite b, nist curve", + doi="10.17487/RFC5903", + } + +@misc{rfc5904, + author="G. Zorn", + title="{RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support}", + howpublished="RFC 5904 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5904", + pages="1--15", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5904.txt", + key="RFC 5904", + abstract={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.}, + keywords="RADIUS, AAA, IEEE, 802.16", + doi="10.17487/RFC5904", + } + +@misc{rfc5905, + author="D. Mills and J. {Martin (Ed.)} and J. Burbank and W. Kasch", + title="{Network Time Protocol Version 4: Protocol and Algorithms Specification}", + howpublished="RFC 5905 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5905", + pages="1--110", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7822", +url="https://www.rfc-editor.org/rfc/rfc5905.txt", + key="RFC 5905", + abstract={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. [STANDARDS-TRACK]}, + keywords="NTP, SNTP, Synchronization", + doi="10.17487/RFC5905", + } + +@misc{rfc5906, + author="B. {Haberman (Ed.)} and D. Mills", + title="{Network Time Protocol Version 4: Autokey Specification}", + howpublished="RFC 5906 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5906", + pages="1--58", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5906.txt", + key="RFC 5906", + abstract={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. 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) op erating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + keywords="ntp, ntpv4, public key cryptography", + doi="10.17487/RFC5906", + } + +@misc{rfc5907, + author="H. Gerstung and C. Elliott and B. {Haberman (Ed.)}", + title="{Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)}", + howpublished="RFC 5907 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5907", + pages="1--26", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5907.txt", + key="RFC 5907", + abstract={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]}, + keywords="", + doi="10.17487/RFC5907", + } + +@misc{rfc5908, + author="R. Gayraud and B. Lourdelet", + title="{Network Time Protocol (NTP) Server Option for DHCPv6}", + howpublished="RFC 5908 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5908", + pages="1--9", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5908.txt", + key="RFC 5908", + abstract={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]}, + keywords="Dynamic Host Configuration Protocol for IPv6", + doi="10.17487/RFC5908", + } + +@misc{rfc5909, + author="J-M. Combes and S. Krishnan and G. Daley", + title="{Securing Neighbor Discovery Proxy: Problem Statement}", + howpublished="RFC 5909 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5909", + pages="1--22", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5909.txt", + key="RFC 5909", + abstract={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. 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. 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 Sta ndards Track specification; it is published for informational purposes.}, + keywords="send, secure neighbor discovery", + doi="10.17487/RFC5909", + } + +@misc{rfc5910, + author="J. Gould and S. Hollenbeck", + title="{Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 5910 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5910", + pages="1--36", + year=2010, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5910.txt", + key="RFC 5910", + abstract={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]}, + keywords="epp, Extensible Provisioning Protocol, xml, dns, security, dnssec, delegation signer, ds", + doi="10.17487/RFC5910", + } + +@misc{rfc5911, + author="P. Hoffman and J. Schaad", + title="{New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME}", + howpublished="RFC 5911 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5911", + pages="1--59", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6268", +url="https://www.rfc-editor.org/rfc/rfc5911.txt", + key="RFC 5911", + abstract={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.}, + keywords="S/MIME, PKIX, ASN.1 modules", + doi="10.17487/RFC5911", + } + +@misc{rfc5912, + author="P. Hoffman and J. Schaad", + title="{New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)}", + howpublished="RFC 5912 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5912", + pages="1--117", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6960", +url="https://www.rfc-editor.org/rfc/rfc5912.txt", + key="RFC 5912", + abstract={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.}, + keywords="S/MIME, PKIX, ASN.1 modules", + doi="10.17487/RFC5912", + } + +@misc{rfc5913, + author="S. Turner and S. Chokhani", + title="{Clearance Attribute and Authority Clearance Constraints Certificate Extension}", + howpublished="RFC 5913 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5913", + pages="1--19", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5913.txt", + key="RFC 5913", + abstract={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]}, + keywords="x.509 certificate", + doi="10.17487/RFC5913", + } + +@misc{rfc5914, + author="R. Housley and S. Ashmore and C. Wallace", + title="{Trust Anchor Format}", + howpublished="RFC 5914 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5914", + pages="1--14", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5914.txt", + key="RFC 5914", + abstract={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]}, + keywords="trust anchor management", + doi="10.17487/RFC5914", + } + +@misc{rfc5915, + author="S. Turner and D. Brown", + title="{Elliptic Curve Private Key Structure}", + howpublished="RFC 5915 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5915", + pages="1--7", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5915.txt", + key="RFC 5915", + abstract={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.}, + keywords="ec, Standards for Efficient Cryptography Group, SECG", + doi="10.17487/RFC5915", + } + +@misc{rfc5916, + author="S. Turner", + title="{Device Owner Attribute}", + howpublished="RFC 5916 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5916", + pages="1--6", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5916.txt", + key="RFC 5916", + abstract={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.}, + doi="10.17487/RFC5916", + } + +@misc{rfc5917, + author="S. Turner", + title="{Clearance Sponsor Attribute}", + howpublished="RFC 5917 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5917", + pages="1--7", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5917.txt", + key="RFC 5917", + abstract={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.}, + doi="10.17487/RFC5917", + } + +@misc{rfc5918, + author="R. Asati and I. Minei and B. Thomas", + title="{Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)}", + howpublished="RFC 5918 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5918", + pages="1--10", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7358", +url="https://www.rfc-editor.org/rfc/rfc5918.txt", + key="RFC 5918", + abstract={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]}, + keywords="Wildcard, Typed Wildcard FEC Element, Typed Wildcard FEC Capability", + doi="10.17487/RFC5918", + } + +@misc{rfc5919, + author="R. Asati and P. Mohapatra and E. Chen and B. Thomas", + title="{Signaling LDP Label Advertisement Completion}", + howpublished="RFC 5919 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5919", + pages="1--9", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5919.txt", + key="RFC 5919", + abstract={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]}, + keywords="label distribution protocol, End-of-LIB, Unrecognized Notification", + doi="10.17487/RFC5919", + } + +@misc{rfc5920, + author="L. {Fang (Ed.)}", + title="{Security Framework for MPLS and GMPLS Networks}", + howpublished="RFC 5920 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5920", + pages="1--66", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5920.txt", + key="RFC 5920", + abstract={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.}, + doi="10.17487/RFC5920", + } + +@misc{rfc5921, + author="M. {Bocci (Ed.)} and S. {Bryant (Ed.)} and D. {Frost (Ed.)} and L. Levrau and L. Berger", + title="{A Framework for MPLS in Transport Networks}", + howpublished="RFC 5921 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5921", + pages="1--56", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6215, 7274", +url="https://www.rfc-editor.org/rfc/rfc5921.txt", + key="RFC 5921", + abstract={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. 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 transpo rt paths, is outside the scope of this document. 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.}, + keywords="multiprotocol label switching, mpls-tp, transport profile, oam, itu-t", + doi="10.17487/RFC5921", + } + +@misc{rfc5922, + author="V. Gurbani and S. Lawrence and A. Jeffrey", + title="{Domain Certificates in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5922 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5922", + pages="1--17", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5922.txt", + key="RFC 5922", + abstract={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]}, + keywords="PKIX, Authentication, Mutual Authentication, X.509, TLS", + doi="10.17487/RFC5922", + } + +@misc{rfc5923, + author="V. {Gurbani (Ed.)} and R. Mahy and B. Tate", + title="{Connection Reuse in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5923 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5923", + pages="1--19", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5923.txt", + key="RFC 5923", + abstract={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]}, + keywords="TCP Connection, SCTP Connection, TLS Connection, Transport Connection, TLS, Virtual Server, Authentication", + doi="10.17487/RFC5923", + } + +@misc{rfc5924, + author="S. Lawrence and V. Gurbani", + title="{Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates}", + howpublished="RFC 5924 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5924", + pages="1--8", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5924.txt", + key="RFC 5924", + abstract={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.}, + keywords="PKIX, SIP Domain, X.509 Certificate", + doi="10.17487/RFC5924", + } + +@misc{rfc5925, + author="J. Touch and A. Mankin and R. Bonica", + title="{The TCP Authentication Option}", + howpublished="RFC 5925 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5925", + pages="1--48", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5925.txt", + key="RFC 5925", + abstract={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 T CP 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]}, + keywords="transmission control protocol, border, gateway, protocol, transmission control message, digest, algorithm", + doi="10.17487/RFC5925", + } + +@misc{rfc5926, + author="G. Lebovitz and E. Rescorla", + title="{Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)}", + howpublished="RFC 5926 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5926", + pages="1--15", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5926.txt", + key="RFC 5926", + abstract={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]}, + keywords="transmission control protocol", + doi="10.17487/RFC5926", + } + +@misc{rfc5927, + author="F. Gont", + title="{ICMP Attacks against TCP}", + howpublished="RFC 5927 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5927", + pages="1--36", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5927.txt", + key="RFC 5927", + abstract={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.}, + keywords="vulnerability, blind attacks, connection-reset attack, performance-degrading attack, throughput-reduction attack, source quench, PMTUD, Path-MTU Discovery, ICMP Destination Unreachable", + doi="10.17487/RFC5927", + } + +@misc{rfc5928, + author="M. Petit-Huguenin", + title="{Traversal Using Relays around NAT (TURN) Resolution Mechanism}", + howpublished="RFC 5928 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5928", + pages="1--11", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7350", +url="https://www.rfc-editor.org/rfc/rfc5928.txt", + key="RFC 5928", + abstract={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]}, + keywords="NAT, Traversal", + doi="10.17487/RFC5928", + } + +@misc{rfc5929, + author="J. Altman and N. Williams and L. Zhu", + title="{Channel Bindings for TLS}", + howpublished="RFC 5929 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5929", + pages="1--15", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5929.txt", + key="RFC 5929", + abstract={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). 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]}, + keywords="TLS, channel, binding, channel-binding, tls-unique, tls-server-end-point, tls-unique-for-telnet", + doi="10.17487/RFC5929", + } + +@misc{rfc5930, + author="S. Shen and Y. Mao and NSS. Murthy", + title="{Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol}", + howpublished="RFC 5930 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5930", + pages="1--6", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5930.txt", + key="RFC 5930", + abstract={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.}, + keywords="initialization vector, IKE\_SA\_INIT", + doi="10.17487/RFC5930", + } + +@misc{rfc5931, + author="D. Harkins and G. Zorn", + title="{Extensible Authentication Protocol (EAP) Authentication Using Only a Password}", + howpublished="RFC 5931 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5931", + pages="1--40", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8146", +url="https://www.rfc-editor.org/rfc/rfc5931.txt", + key="RFC 5931", + abstract={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.}, + keywords="Password Authenticated Key Exchange, Dictionary Attack, Authentication EAP", + doi="10.17487/RFC5931", + } + +@misc{rfc5932, + author="A. Kato and M. Kanda and S. Kanno", + title="{Camellia Cipher Suites for TLS}", + howpublished="RFC 5932 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5932", + pages="1--6", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5932.txt", + key="RFC 5932", + abstract={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]}, + keywords="block cipher, security, camellia, tls, cbc, sha2, camellia encryption algorithm", + doi="10.17487/RFC5932", + } + +@misc{rfc5933, + author="V. {Dolmatov (Ed.)} and A. Chuprina and I. Ustinov", + title="{Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC}", + howpublished="RFC 5933 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5933", + pages="1--9", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6944", +url="https://www.rfc-editor.org/rfc/rfc5933.txt", + key="RFC 5933", + abstract={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). [STANDARDS-TRACK]}, + keywords="domain name system security extensions, ECC", + doi="10.17487/RFC5933", + } + +@misc{rfc5934, + author="R. Housley and S. Ashmore and C. Wallace", + title="{Trust Anchor Management Protocol (TAMP)}", + howpublished="RFC 5934 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5934", + pages="1--91", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5934.txt", + key="RFC 5934", + abstract={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]}, + keywords="trust anchors, TA", + doi="10.17487/RFC5934", + } + +@misc{rfc5935, + author="M. Ellison and B. Natale", + title="{Expressing SNMP SMI Datatypes in XML Schema Definition Language}", + howpublished="RFC 5935 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5935", + pages="1--14", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5935.txt", + key="RFC 5935", + abstract={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]}, + keywords="structure of management information", + doi="10.17487/RFC5935", + } + +@misc{rfc5936, + author="E. Lewis and A. {Hoenes (Ed.)}", + title="{DNS Zone Transfer Protocol (AXFR)}", + howpublished="RFC 5936 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5936", + pages="1--29", + year=2010, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5936.txt", + key="RFC 5936", + abstract={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. 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]}, + keywords="authoritative transfer, AXFR mechanism", + doi="10.17487/RFC5936", + } + +@misc{rfc5937, + author="S. Ashmore and C. Wallace", + title="{Using Trust Anchor Constraints during Certification Path Processing}", + howpublished="RFC 5937 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5937", + pages="1--8", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5937.txt", + key="RFC 5937", + abstract={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.}, + keywords="TA", + doi="10.17487/RFC5937", + } + +@misc{rfc5938, + author="A. Morton and M. Chiba", + title="{Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)}", + howpublished="RFC 5938 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5938", + pages="1--17", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5938.txt", + key="RFC 5938", + abstract={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]}, + keywords="", + doi="10.17487/RFC5938", + } + +@misc{rfc5939, + author="F. Andreasen", + title="{Session Description Protocol (SDP) Capability Negotiation}", + howpublished="RFC 5939 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5939", + pages="1--77", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6871", +url="https://www.rfc-editor.org/rfc/rfc5939.txt", + key="RFC 5939", + abstract={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. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedure s to use those parameters in a backwards compatible manner. 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]}, + keywords="multimedia session, session announcement, session invitation", + doi="10.17487/RFC5939", + } + +@misc{rfc5940, + author="S. Turner and R. Housley", + title="{Additional Cryptographic Message Syntax (CMS) Revocation Information Choices}", + howpublished="RFC 5940 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5940", + pages="1--9", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5940.txt", + key="RFC 5940", + abstract={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]}, + keywords="online certificate status protocol, ocsp, server-based certificate validation protocol, scvp", + doi="10.17487/RFC5940", + } + +@misc{rfc5941, + author="D. M'Raihi and S. Boeyen and M. Grandcolas and S. Bajaj", + title="{Sharing Transaction Fraud Data}", + howpublished="RFC 5941 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5941", + pages="1--27", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5941.txt", + key="RFC 5941", + abstract={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.}, + keywords="thraud, incident object description exchange format, iodef", + doi="10.17487/RFC5941", + } + +@misc{rfc5942, + author="H. Singh and W. Beebee and E. Nordmark", + title="{IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes}", + howpublished="RFC 5942 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5942", + pages="1--11", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5942.txt", + key="RFC 5942", + abstract={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]}, + keywords="", + doi="10.17487/RFC5942", + } + +@misc{rfc5943, + author="B. {Haberman (Ed.)}", + title="{A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing}", + howpublished="RFC 5943 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5943", + pages="1--4", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5943.txt", + key="RFC 5943", + abstract={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]}, + keywords="", + doi="10.17487/RFC5943", + } + +@misc{rfc5944, + author="C. {Perkins (Ed.)}", + title="{IP Mobility Support for IPv4, Revised}", + howpublished="RFC 5944 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5944", + pages="1--100", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5944.txt", + key="RFC 5944", + abstract={This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]}, + keywords="MOBILEIPSUPIP, Internet Protocol, MIPv4", + doi="10.17487/RFC5944", + } + +@misc{rfc5945, + author="F. Le Faucheur and J. Manner and D. Wing and A. Guillou", + title="{Resource Reservation Protocol (RSVP) Proxy Approaches}", + howpublished="RFC 5945 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5945", + pages="1--50", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5945.txt", + key="RFC 5945", + abstract={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.}, + doi="10.17487/RFC5945", + } + +@misc{rfc5946, + author="F. Le Faucheur and J. Manner and A. Narayanan and A. Guillou and H. Malik", + title="{Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy}", + howpublished="RFC 5946 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5946", + pages="1--35", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5946.txt", + key="RFC 5946", + abstract={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 the se extensions. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC5946", + } + +@misc{rfc5947, + author="J. Elwell and H. Kaplan", + title="{Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)}", + howpublished="RFC 5947 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5947", + pages="1--13", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5947.txt", + key="RFC 5947", + abstract={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.}, + keywords="Trunking, pbx, private branch exchange", + doi="10.17487/RFC5947", + } + +@misc{rfc5948, + author="S. Madanapalli and S. Park and S. Chakrabarti and G. Montenegro", + title="{Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16}", + howpublished="RFC 5948 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5948", + pages="1--13", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5948.txt", + key="RFC 5948", + abstract={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. 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]}, + keywords="packet cs", + doi="10.17487/RFC5948", + } + +@misc{rfc5949, + author="H. Yokota and K. Chowdhury and R. Koodli and B. Patil and F. Xia", + title="{Fast Handovers for Proxy Mobile IPv6}", + howpublished="RFC 5949 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5949", + pages="1--32", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5949.txt", + key="RFC 5949", + abstract={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. 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 exte nsions 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]}, + keywords="PFMIPv6, handoff, PMIPv6, predictive, reactive", + doi="10.17487/RFC5949", + } + +@misc{rfc5950, + author="S. {Mansfield (Ed.)} and E. {Gray (Ed.)} and K. {Lam (Ed.)}", + title="{Network Management Framework for MPLS-based Transport Networks}", + howpublished="RFC 5950 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5950", + pages="1--18", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5950.txt", + key="RFC 5950", + abstract={This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). 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. 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. 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.}, + keywords="mpls-tp, network management framework", + doi="10.17487/RFC5950", + } + +@misc{rfc5951, + author="K. Lam and S. Mansfield and E. Gray", + title="{Network Management Requirements for MPLS-based Transport Networks}", + howpublished="RFC 5951 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5951", + pages="1--24", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5951.txt", + key="RFC 5951", + abstract={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]}, + keywords="MPLS Transport Profile, mpls-tp", + doi="10.17487/RFC5951", + } + +@misc{rfc5952, + author="S. Kawamura and M. Kawashima", + title="{A Recommendation for IPv6 Address Text Representation}", + howpublished="RFC 5952 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5952", + pages="1--14", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5952.txt", + key="RFC 5952", + abstract={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]}, + keywords="IPv6, text representation, canonical", + doi="10.17487/RFC5952", + } + +@misc{rfc5953, + author="W. Hardaker", + title="{Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 5953 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5953", + pages="1--65", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6353", +url="https://www.rfc-editor.org/rfc/rfc5953.txt", + key="RFC 5953", + abstract={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. 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. This document also defines a portion of the Mana gement Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]}, + keywords="dtls, datagram transport layer security, tls transport model, tlstm, SNMP-TLS-TM-MIB", + doi="10.17487/RFC5953", + } + +@misc{rfc5954, + author="V. {Gurbani (Ed.)} and B. {Carpenter (Ed.)} and B. {Tate (Ed.)}", + title="{Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261}", + howpublished="RFC 5954 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5954", + pages="1--7", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5954.txt", + key="RFC 5954", + abstract={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]}, + keywords="SIP, session initiation protocol, Augmented Backus-Naur Form, Uniform Resource Identifier, IPv6reference, IPv6address", + doi="10.17487/RFC5954", + } + +@misc{rfc5955, + author="A. Santoni", + title="{The application/timestamped-data Media Type}", + howpublished="RFC 5955 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5955", + pages="1--3", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5955.txt", + key="RFC 5955", + abstract={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.}, + keywords="TimeStampedData envelopes", + doi="10.17487/RFC5955", + } + +@misc{rfc5956, + author="A. Begen", + title="{Forward Error Correction Grouping Semantics in the Session Description Protocol}", + howpublished="RFC 5956 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5956", + pages="1--14", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5956.txt", + key="RFC 5956", + abstract={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]}, + keywords="FEC, loss repair, grouping, sdp, media lines", + doi="10.17487/RFC5956", + } + +@misc{rfc5957, + author="D. Karp", + title="{Display-Based Address Sorting for the IMAP4 SORT Extension}", + howpublished="RFC 5957 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5957", + pages="1--5", + year=2010, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5957.txt", + key="RFC 5957", + abstract={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]}, + keywords="Internet Message Access Protocol", + doi="10.17487/RFC5957", + } + +@misc{rfc5958, + author="S. Turner", + title="{Asymmetric Key Packages}", + howpublished="RFC 5958 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5958", + pages="1--14", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5958.txt", + key="RFC 5958", + abstract={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]}, + keywords="private key, private-key information, rsa laboratories, private-key syntax, change control", + doi="10.17487/RFC5958", + } + +@misc{rfc5959, + author="S. Turner", + title="{Algorithms for Asymmetric Key Package Content Type}", + howpublished="RFC 5959 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5959", + pages="1--7", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6162", +url="https://www.rfc-editor.org/rfc/rfc5959.txt", + key="RFC 5959", + abstract={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]}, + keywords="EncryptedPrivateKeyInfo, AsymmetricKeyPackage", + doi="10.17487/RFC5959", + } + +@misc{rfc5960, + author="D. {Frost (Ed.)} and S. {Bryant (Ed.)} and M. {Bocci (Ed.)}", + title="{MPLS Transport Profile Data Plane Architecture}", + howpublished="RFC 5960 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5960", + pages="1--15", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7274", +url="https://www.rfc-editor.org/rfc/rfc5960.txt", + key="RFC 5960", + abstract={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. 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]}, + keywords="mpls-tp, transport profile, itu-t, dataplane, gal, gach", + doi="10.17487/RFC5960", + } + +@misc{rfc5961, + author="A. Ramaiah and R. Stewart and M. Dalal", + title="{Improving TCP's Robustness to Blind In-Window Attacks}", + howpublished="RFC 5961 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5961", + pages="1--19", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5961.txt", + key="RFC 5961", + abstract={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]}, + keywords="RST, SYN, FIN, attack, Data Injection, vulnerability, blind attacks, BGP, spoof, mitigation", + doi="10.17487/RFC5961", + } + +@misc{rfc5962, + author="H. Schulzrinne and V. Singh and H. Tschofenig and M. Thomson", + title="{Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)}", + howpublished="RFC 5962 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5962", + pages="1--11", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5962.txt", + key="RFC 5962", + abstract={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]}, + keywords="PIDF-LO,location,dynamic,speed,velocity,orientation", + doi="10.17487/RFC5962", + } + +@misc{rfc5963, + author="R. Gagliano", + title="{IPv6 Deployment in Internet Exchange Points (IXPs)}", + howpublished="RFC 5963 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5963", + pages="1--10", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5963.txt", + key="RFC 5963", + abstract={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.}, + keywords="IPv6, IXP, deployment, exchange", + doi="10.17487/RFC5963", + } + +@misc{rfc5964, + author="J. Winterbottom and M. Thomson", + title="{Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries}", + howpublished="RFC 5964 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5964", + pages="1--11", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5964.txt", + key="RFC 5964", + abstract={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]}, + keywords="hole, polygon, pidf-lo, service boundary, location, LoST", + doi="10.17487/RFC5964", + } + +@misc{rfc5965, + author="Y. Shafranovich and J. Levine and M. Kucherawy", + title="{An Extensible Format for Email Feedback Reports}", + howpublished="RFC 5965 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5965", + pages="1--25", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6650", +url="https://www.rfc-editor.org/rfc/rfc5965.txt", + key="RFC 5965", + abstract={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]}, + keywords="feedback-report", + doi="10.17487/RFC5965", + } + +@misc{rfc5966, + author="R. Bellis", + title="{DNS Transport over TCP - Implementation Requirements}", + howpublished="RFC 5966 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5966", + pages="1--7", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7766", +url="https://www.rfc-editor.org/rfc/rfc5966.txt", + key="RFC 5966", + abstract={This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS-TRACK]}, + keywords="DNS, TCP/IP", + doi="10.17487/RFC5966", + } + +@misc{rfc5967, + author="S. Turner", + title="{The application/pkcs10 Media Type}", + howpublished="RFC 5967 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5967", + pages="1--6", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5967.txt", + key="RFC 5967", + abstract={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.}, + doi="10.17487/RFC5967", + } + +@misc{rfc5968, + author="J. Ott and C. Perkins", + title="{Guidelines for Extending the RTP Control Protocol (RTCP)}", + howpublished="RFC 5968 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5968", + pages="1--17", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5968.txt", + key="RFC 5968", + abstract={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.}, + keywords="real-time transport protocol", + doi="10.17487/RFC5968", + } + +@misc{rfc5969, + author="W. Townsley and O. Troan", + title="{IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification}", + howpublished="RFC 5969 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5969", + pages="1--18", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5969.txt", + key="RFC 5969", + abstract={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]}, + keywords="6rd, Provider 6to4, IPv6 softwire, IPv6 Transition, 6to4", + doi="10.17487/RFC5969", + } + +@misc{rfc5970, + author="T. Huth and J. Freimann and V. Zimmer and D. Thaler", + title="{DHCPv6 Options for Network Boot}", + howpublished="RFC 5970 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5970", + pages="1--11", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5970.txt", + key="RFC 5970", + abstract={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]}, + keywords="boot, IPv6, DHCPv6", + doi="10.17487/RFC5970", + } + +@misc{rfc5971, + author="H. Schulzrinne and R. Hancock", + title="{GIST: General Internet Signalling Transport}", + howpublished="RFC 5971 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5971", + pages="1--154", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5971.txt", + key="RFC 5971", + abstract={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.}, + keywords="nsis, next steps in signaling", + doi="10.17487/RFC5971", + } + +@misc{rfc5972, + author="T. Tsenov and H. Tschofenig and X. {Fu (Ed.)} and C. Aoun and E. Davies", + title="{General Internet Signaling Transport (GIST) State Machine}", + howpublished="RFC 5972 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5972", + pages="1--27", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5972.txt", + key="RFC 5972", + doi="10.17487/RFC5972", + } + +@misc{rfc5973, + author="M. Stiemerling and H. Tschofenig and C. Aoun and E. Davies", + title="{NAT/Firewall NSIS Signaling Layer Protocol (NSLP)}", + howpublished="RFC 5973 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5973", + pages="1--90", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5973.txt", + key="RFC 5973", + abstract={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.}, + keywords="Next Steps in Signaling, NSIS, Path-coupled signaling, Middlebox", + doi="10.17487/RFC5973", + } + +@misc{rfc5974, + author="J. Manner and G. Karagiannis and A. McDonald", + title="{NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling}", + howpublished="RFC 5974 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5974", + pages="1--102", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5974.txt", + key="RFC 5974", + abstract={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.}, + keywords="QoS", + doi="10.17487/RFC5974", + } + +@misc{rfc5975, + author="G. {Ash (Ed.)} and A. {Bader (Ed.)} and C. {Kappler (Ed.)} and D. {Oran (Ed.)}", + title="{QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)}", + howpublished="RFC 5975 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5975", + pages="1--64", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5975.txt", + key="RFC 5975", + abstract={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 fo r the Internet community.}, + doi="10.17487/RFC5975", + } + +@misc{rfc5976, + author="G. Ash and A. Morton and M. Dolly and P. Tarapore and C. Dvorak and Y. El Mghazli", + title="{Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes}", + howpublished="RFC 5976 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5976", + pages="1--19", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5976.txt", + key="RFC 5976", + abstract={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.}, + keywords="qos-nslp, qos-nslp quality-of-service model, qspec", + doi="10.17487/RFC5976", + } + +@misc{rfc5977, + author="A. Bader and L. Westberg and G. Karagiannis and C. Kappler and T. Phelan", + title="{RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv}", + howpublished="RFC 5977 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5977", + pages="1--128", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5977.txt", + key="RFC 5977", + abstract={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.}, + keywords="next steps in signaling, resource managment in diffserv", + doi="10.17487/RFC5977", + } + +@misc{rfc5978, + author="J. Manner and R. Bless and J. Loughney and E. {Davies (Ed.)}", + title="{Using and Extending the NSIS Protocol Family}", + howpublished="RFC 5978 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5978", + pages="1--30", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5978.txt", + key="RFC 5978", + abstract={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.}, + keywords="Signaling, NTLP, NSLP, GIST, QoS NSLP, NAT/Firewall, NSLP, IP resources, Extensibility", + doi="10.17487/RFC5978", + } + +@misc{rfc5979, + author="C. Shen and H. Schulzrinne and S. Lee and J. Bang", + title="{NSIS Operation over IP Tunnels}", + howpublished="RFC 5979 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5979", + pages="1--27", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5979.txt", + key="RFC 5979", + abstract={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.}, + keywords="nsis qos, next steps in signaling", + doi="10.17487/RFC5979", + } + +@misc{rfc5980, + author="T. {Sanda (Ed.)} and X. Fu and S. Jeong and J. Manner and H. Tschofenig", + title="{NSIS Protocol Operation in Mobile Environments}", + howpublished="RFC 5980 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5980", + pages="1--32", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5980.txt", + key="RFC 5980", + abstract={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.}, + doi="10.17487/RFC5980", + } + +@misc{rfc5981, + author="J. Manner and M. Stiemerling and H. Tschofenig and R. {Bless (Ed.)}", + title="{Authorization for NSIS Signaling Layer Protocols}", + howpublished="RFC 5981 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5981", + pages="1--37", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5981.txt", + key="RFC 5981", + abstract={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.}, + keywords="Next Steps in Signaling, gist, General Internet Signaling Transport", + doi="10.17487/RFC5981", + } + +@misc{rfc5982, + author="A. {Kobayashi (Ed.)} and B. {Claise (Ed.)}", + title="{IP Flow Information Export (IPFIX) Mediation: Problem Statement}", + howpublished="RFC 5982 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5982", + pages="1--25", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5982.txt", + key="RFC 5982", + abstract={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.}, + keywords="flow-based measurement", + doi="10.17487/RFC5982", + } + +@misc{rfc5983, + author="R. Gellens", + title="{Mailing Lists and Internationalized Email Addresses}", + howpublished="RFC 5983 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5983", + pages="1--10", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6783", +url="https://www.rfc-editor.org/rfc/rfc5983.txt", + key="RFC 5983", + abstract={This document describes considerations for mailing lists with the introduction of internationalized email addresses. 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.}, + doi="10.17487/RFC5983", + } + +@misc{rfc5984, + author="K-M. Moller", + title="{Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding}", + howpublished="RFC 5984 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="5984", + pages="1--9", + year=2011, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5984.txt", + key="RFC 5984", + abstract={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.}, + keywords="extra sensory perception", + doi="10.17487/RFC5984", + } + +@misc{rfc5985, + author="M. {Barnes (Ed.)}", + title="{HTTP-Enabled Location Delivery (HELD)}", + howpublished="RFC 5985 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5985", + pages="1--39", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7840", +url="https://www.rfc-editor.org/rfc/rfc5985.txt", + key="RFC 5985", + abstract={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]}, + keywords="layer 7 location configuration protocol, l7 lcp", + doi="10.17487/RFC5985", + } + +@misc{rfc5986, + author="M. Thomson and J. Winterbottom", + title="{Discovering the Local Location Information Server (LIS)}", + howpublished="RFC 5986 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5986", + pages="1--16", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5986.txt", + key="RFC 5986", + abstract={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]}, + keywords="u-naptr, uri-enabled naptr", + doi="10.17487/RFC5986", + } + +@misc{rfc5987, + author="J. Reschke", + title="{Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters}", + howpublished="RFC 5987 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="5987", + pages="1--10", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8187", +url="https://www.rfc-editor.org/rfc/rfc5987.txt", + key="RFC 5987", + abstract={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]}, + keywords="HTTP, header field parameter, internationalization", + doi="10.17487/RFC5987", + } + +@misc{rfc5988, + author="M. Nottingham", + title="{Web Linking}", + howpublished="RFC 5988 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5988", + pages="1--23", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8288", +url="https://www.rfc-editor.org/rfc/rfc5988.txt", + key="RFC 5988", + abstract={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]}, + keywords="Link, linking, http header, link relation, web", + doi="10.17487/RFC5988", + } + +@misc{rfc5989, + author="A.B. Roach", + title="{A SIP Event Package for Subscribing to Changes to an HTTP Resource}", + howpublished="RFC 5989 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5989", + pages="1--19", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5989.txt", + key="RFC 5989", + abstract={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]}, + keywords="Link Relations, Syndication, Atom", + doi="10.17487/RFC5989", + } + +@misc{rfc5990, + author="J. Randall and B. Kaliski and J. Brainard and S. Turner", + title="{Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 5990 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5990", + pages="1--27", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5990.txt", + key="RFC 5990", + abstract={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.}, + keywords="key encapsulation mechanism, generic hybrid cipher", + doi="10.17487/RFC5990", + } + +@misc{rfc5991, + author="D. Thaler and S. Krishnan and J. Hoagland", + title="{Teredo Security Updates}", + howpublished="RFC 5991 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5991", + pages="1--10", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5991.txt", + key="RFC 5991", + abstract={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]}, + keywords="teredo ipv6 address", + doi="10.17487/RFC5991", + } + +@misc{rfc5992, + author="S. Sharikov and D. Miloshevic and J. Klensin", + title="{Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic}", + howpublished="RFC 5992 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5992", + pages="1--21", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5992.txt", + key="RFC 5992", + abstract={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.}, + keywords="Bosnian and Serbian, Bulgarian, Byelorussian, Belarusian, Belarusan, Kildin Sami, Macedonian, Montenegrin, Russian, Ukrainian", + doi="10.17487/RFC5992", + } + +@misc{rfc5993, + author="X. Duan and S. Wang and M. Westerlund and K. Hellwig and I. Johansson", + title="{RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)}", + howpublished="RFC 5993 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5993", + pages="1--18", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5993.txt", + key="RFC 5993", + abstract={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]}, + keywords="speech codec, real-time transport protocol", + doi="10.17487/RFC5993", + } + +@misc{rfc5994, + author="S. {Bryant (Ed.)} and M. Morrow and G. Swallow and R. Cherukuri and T. Nadeau and N. Harrison and B. Niven-Jenkins", + title="{Application of Ethernet Pseudowires to MPLS Transport Networks}", + howpublished="RFC 5994 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5994", + pages="1--11", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5994.txt", + key="RFC 5994", + abstract={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. 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. 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 fo r informational purposes.}, + keywords="mpls-tp", + doi="10.17487/RFC5994", + } + +@misc{rfc5995, + author="J. Reschke", + title="{Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections}", + howpublished="RFC 5995 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5995", + pages="1--12", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5995.txt", + key="RFC 5995", + abstract={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''. 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. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned ``add collection member '' semantics. [STANDARDS-TRACK]}, + keywords="HTTP, POST, WebDAV, Collections, Collection Members", + doi="10.17487/RFC5995", + } + +@misc{rfc5996, + author="C. Kaufman and P. Hoffman and Y. Nir and P. Eronen", + title="{Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 5996 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5996", + pages="1--138", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7296, updated by RFCs 5998, 6989", +url="https://www.rfc-editor.org/rfc/rfc5996.txt", + key="RFC 5996", + abstract={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]}, + keywords="IKE, IPsec", + doi="10.17487/RFC5996", + } + +@misc{rfc5997, + author="A. DeKok", + title="{Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol}", + howpublished="RFC 5997 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="5997", + pages="1--24", + year=2010, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5997.txt", + key="RFC 5997", + abstract={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.}, + keywords="status-server", + doi="10.17487/RFC5997", + } + +@misc{rfc5998, + author="P. Eronen and H. Tschofenig and Y. Sheffer", + title="{An Extension for EAP-Only Authentication in IKEv2}", + howpublished="RFC 5998 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="5998", + pages="1--16", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc5998.txt", + key="RFC 5998", + abstract={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. 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]}, + keywords="mutual authentication, password, credentials, AAA, key agreement, channel binding", + doi="10.17487/RFC5998", + } + +@misc{rfc6001, + author="D. Papadimitriou and M. Vigoureux and K. Shiomoto and D. Brungard and JL. Le Roux", + title="{Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)}", + howpublished="RFC 6001 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6001", + pages="1--24", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6001.txt", + key="RFC 6001", + abstract={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). 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]}, + keywords="", + doi="10.17487/RFC6001", + } + +@misc{rfc6002, + author="L. Berger and D. Fedyk", + title="{Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions}", + howpublished="RFC 6002 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6002", + pages="1--10", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6002.txt", + key="RFC 6002", + abstract={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]}, + keywords="Generalized Multi-Protocol Label Switching", + doi="10.17487/RFC6002", + } + +@misc{rfc6003, + author="D. Papadimitriou", + title="{Ethernet Traffic Parameters}", + howpublished="RFC 6003 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6003", + pages="1--14", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6003.txt", + key="RFC 6003", + abstract={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]}, + keywords="mef, Metro Ethernet Forum, MEF10.1", + doi="10.17487/RFC6003", + } + +@misc{rfc6004, + author="L. Berger and D. Fedyk", + title="{Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching}", + howpublished="RFC 6004 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6004", + pages="1--15", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6004.txt", + key="RFC 6004", + keywords="Generalized Multi-Protocol Label Switching, Metro Ethernet Forum, MEF", + doi="10.17487/RFC6004", + } + +@misc{rfc6005, + author="L. Berger and D. Fedyk", + title="{Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)}", + howpublished="RFC 6005 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6005", + pages="1--10", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6005.txt", + key="RFC 6005", + abstract={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]}, + keywords="mef, itu, International Telecommunication Union, i-nni, internal nni", + doi="10.17487/RFC6005", + } + +@misc{rfc6006, + author="Q. {Zhao (Ed.)} and D. {King (Ed.)} and F. Verhaeghe and T. Takeda and Z. Ali and J. Meuric", + title="{Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths}", + howpublished="RFC 6006 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6006", + pages="1--33", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8306", +url="https://www.rfc-editor.org/rfc/rfc6006.txt", + key="RFC 6006", + abstract={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. 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]}, + keywords="END-POINTS, fragmentation", + doi="10.17487/RFC6006", + } + +@misc{rfc6007, + author="I. Nishioka and D. King", + title="{Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations}", + howpublished="RFC 6007 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6007", + pages="1--18", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6007.txt", + key="RFC 6007", + abstract={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. 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 e nvironments. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + doi="10.17487/RFC6007", + } + +@misc{rfc6008, + author="M. Kucherawy", + title="{Authentication-Results Registration for Differentiating among Cryptographic Results}", + howpublished="RFC 6008 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6008", + pages="1--7", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6008.txt", + key="RFC 6008", + abstract={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]}, + keywords="DKIM, DomainKeys, SenderID, SPF, Authentication, Reputation", + doi="10.17487/RFC6008", + } + +@misc{rfc6009, + author="N. Freed", + title="{Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions}", + howpublished="RFC 6009 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6009", + pages="1--15", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6009.txt", + key="RFC 6009", + abstract={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]}, + keywords="SMTP, ESMTP, Sieve", + doi="10.17487/RFC6009", + } + +@misc{rfc6010, + author="R. Housley and S. Ashmore and C. Wallace", + title="{Cryptographic Message Syntax (CMS) Content Constraints Extension}", + howpublished="RFC 6010 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6010", + pages="1--38", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6010.txt", + key="RFC 6010", + abstract={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]}, + keywords="authorization, PKI, certificate, trust anchor, TAMP,", + doi="10.17487/RFC6010", + } + +@misc{rfc6011, + author="S. {Lawrence (Ed.)} and J. Elwell", + title="{Session Initiation Protocol (SIP) User Agent Configuration}", + howpublished="RFC 6011 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6011", + pages="1--29", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6011.txt", + key="RFC 6011", + abstract={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.}, + keywords="HTTP, DHCP, DHCPv6", + doi="10.17487/RFC6011", + } + +@misc{rfc6012, + author="J. Salowey and T. Petch and R. Gerhards and H. Feng", + title="{Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog}", + howpublished="RFC 6012 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6012", + pages="1--12", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6012.txt", + key="RFC 6012", + abstract={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. [STANDARDS-TRACK]}, + keywords="TLS", + doi="10.17487/RFC6012", + } + +@misc{rfc6013, + author="W. Simpson", + title="{TCP Cookie Transactions (TCPCT)}", + howpublished="RFC 6013 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6013", + pages="1--37", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc6013.txt", + key="RFC 6013", + abstract={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.}, + doi="10.17487/RFC6013", + } + +@misc{rfc6014, + author="P. Hoffman", + title="{Cryptographic Algorithm Identifier Allocation for DNSSEC}", + howpublished="RFC 6014 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6014", + pages="1--6", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6014.txt", + key="RFC 6014", + abstract={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]}, + keywords="DNSSEC, digital signatures, algorithms", + doi="10.17487/RFC6014", + } + +@misc{rfc6015, + author="A. Begen", + title="{RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)}", + howpublished="RFC 6015 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6015", + pages="1--31", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6015.txt", + key="RFC 6015", + abstract={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]}, + keywords="FEC, interleaving, loss repair, loss protection, DVB AL-FEC", + doi="10.17487/RFC6015", + } + +@misc{rfc6016, + author="B. Davie and F. Le Faucheur and A. Narayanan", + title="{Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs}", + howpublished="RFC 6016 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6016", + pages="1--38", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6016.txt", + key="RFC 6016", + abstract={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]}, + keywords="l3vpn", + doi="10.17487/RFC6016", + } + +@misc{rfc6017, + author="K. {Meadors (Ed.)}", + title="{Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field}", + howpublished="RFC 6017 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6017", + pages="1--5", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6017.txt", + key="RFC 6017", + abstract={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.}, + keywords="EDIINT-Features", + doi="10.17487/RFC6017", + } + +@misc{rfc6018, + author="F. Baker and W. Harrop and G. Armitage", + title="{IPv4 and IPv6 Greynets}", + howpublished="RFC 6018 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6018", + pages="1--9", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6018.txt", + key="RFC 6018", + abstract={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.}, + keywords="darknets", + doi="10.17487/RFC6018", + } + +@misc{rfc6019, + author="R. Housley", + title="{BinaryTime: An Alternate Format for Representing Date and Time in ASN.1}", + howpublished="RFC 6019 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6019", + pages="1--6", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6019.txt", + key="RFC 6019", + abstract={This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]}, + keywords="signing-time attribute, cryptographic message syntax, cms, SignedData, AuthenticatedData", + doi="10.17487/RFC6019", + } + +@misc{rfc6020, + author="M. {Bjorklund (Ed.)}", + title="{YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)}", + howpublished="RFC 6020 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6020", + pages="1--173", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6020.txt", + key="RFC 6020", + abstract={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]}, + keywords="NETCONF, XML, data modelling", + doi="10.17487/RFC6020", + } + +@misc{rfc6021, + author="J. {Schoenwaelder (Ed.)}", + title="{Common YANG Data Types}", + howpublished="RFC 6021 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6021", + pages="1--26", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6991", +url="https://www.rfc-editor.org/rfc/rfc6021.txt", + key="RFC 6021", + abstract={This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]}, + keywords="YANG, NETCONF", + doi="10.17487/RFC6021", + } + +@misc{rfc6022, + author="M. Scott and M. Bjorklund", + title="{YANG Module for NETCONF Monitoring}", + howpublished="RFC 6022 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6022", + pages="1--28", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6022.txt", + key="RFC 6022", + abstract={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 <get-schema> operation to retrieve them. [STANDARDS-TRACK]}, + keywords="XML, NETCONF, YANG, monitoring", + doi="10.17487/RFC6022", + } + +@misc{rfc6023, + author="Y. Nir and H. Tschofenig and H. Deng and R. Singh", + title="{A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)}", + howpublished="RFC 6023 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6023", + pages="1--7", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6023.txt", + key="RFC 6023", + abstract={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.}, + doi="10.17487/RFC6023", + } + +@misc{rfc6024, + author="R. Reddy and C. Wallace", + title="{Trust Anchor Management Requirements}", + howpublished="RFC 6024 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6024", + pages="1--14", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6024.txt", + key="RFC 6024", + abstract={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.}, + keywords="PKI, certificates, digital signatures", + doi="10.17487/RFC6024", + } + +@misc{rfc6025, + author="C. Wallace and C. Gardiner", + title="{ASN.1 Translation}", + howpublished="RFC 6025 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6025", + pages="1--19", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6025.txt", + key="RFC 6025", + abstract={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.}, + keywords="Basic Encoding Rules, Distinguished Encoding Rules, PKIX, S/MIME", + doi="10.17487/RFC6025", + } + +@misc{rfc6026, + author="R. Sparks and T. Zourzouvillys", + title="{Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests}", + howpublished="RFC 6026 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6026", + pages="1--20", + year=2010, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6026.txt", + key="RFC 6026", + abstract={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]}, + keywords="state machine, retransmission", + doi="10.17487/RFC6026", + } + +@misc{rfc6027, + author="Y. Nir", + title="{IPsec Cluster Problem Statement}", + howpublished="RFC 6027 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6027", + pages="1--12", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6027.txt", + key="RFC 6027", + abstract={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.}, + keywords="IKE, IKEv2, high-availability, load-sharing, failover, hot-standby", + doi="10.17487/RFC6027", + } + +@misc{rfc6028, + author="G. Camarillo and A. Keranen", + title="{Host Identity Protocol (HIP) Multi-Hop Routing Extension}", + howpublished="RFC 6028 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6028", + pages="1--10", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6028.txt", + key="RFC 6028", + abstract={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.}, + keywords="source routing, route recording, overlay network", + doi="10.17487/RFC6028", + } + +@misc{rfc6029, + author="I. Rimac and V. Hilt and M. Tomsu and V. Gurbani and E. Marocco", + title="{A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem}", + howpublished="RFC 6029 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6029", + pages="1--19", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6029.txt", + key="RFC 6029", + abstract={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.}, + keywords="Peer-to-Peer, topology estimation, Internet coordinate system", + doi="10.17487/RFC6029", + } + +@misc{rfc6030, + author="P. Hoyer and M. Pei and S. Machani", + title="{Portable Symmetric Key Container (PSKC)}", + howpublished="RFC 6030 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6030", + pages="1--58", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6030.txt", + key="RFC 6030", + abstract={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]}, + keywords="Symmetric Key, provisioning, AES, 3DES, TDES, OTP, Key transport format, key provisioning format, symmetric key protection, symmetric key transport, PIN transport, PIN, provisioning, PIN Policy, key usage policy", + doi="10.17487/RFC6030", + } + +@misc{rfc6031, + author="S. Turner and R. Housley", + title="{Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type}", + howpublished="RFC 6031 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6031", + pages="1--29", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6031.txt", + key="RFC 6031", + abstract={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]}, + keywords="", + doi="10.17487/RFC6031", + } + +@misc{rfc6032, + author="S. Turner and R. Housley", + title="{Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type}", + howpublished="RFC 6032 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6032", + pages="1--11", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6032.txt", + key="RFC 6032", + abstract={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]}, + keywords="CCC, CMS content constraints", + doi="10.17487/RFC6032", + } + +@misc{rfc6033, + author="S. Turner", + title="{Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type}", + howpublished="RFC 6033 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6033", + pages="1--5", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6161", +url="https://www.rfc-editor.org/rfc/rfc6033.txt", + key="RFC 6033", + abstract={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]}, + keywords="", + doi="10.17487/RFC6033", + } + +@misc{rfc6034, + author="D. Thaler", + title="{Unicast-Prefix-Based IPv4 Multicast Addresses}", + howpublished="RFC 6034 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6034", + pages="1--5", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6034.txt", + key="RFC 6034", + abstract={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]}, + keywords="internet protocol", + doi="10.17487/RFC6034", + } + +@misc{rfc6035, + author="A. Pendleton and A. Clark and A. Johnston and H. Sinnreich", + title="{Session Initiation Protocol Event Package for Voice Quality Reporting}", + howpublished="RFC 6035 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6035", + pages="1--41", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6035.txt", + key="RFC 6035", + abstract={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]}, + keywords="sip, Voice over Internet Protocol, voip, RTP Control Protocol Extended Reports, RTCP-XR", + doi="10.17487/RFC6035", + } + +@misc{rfc6036, + author="B. Carpenter and S. Jiang", + title="{Emerging Service Provider Scenarios for IPv6 Deployment}", + howpublished="RFC 6036 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6036", + pages="1--23", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6036.txt", + key="RFC 6036", + abstract={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.}, + keywords="isp", + doi="10.17487/RFC6036", + } + +@misc{rfc6037, + author="E. {Rosen (Ed.)} and Y. {Cai (Ed.)} and IJ. Wijnands", + title="{Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs}", + howpublished="RFC 6037 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6037", + pages="1--25", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6037.txt", + key="RFC 6037", + abstract={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.}, + keywords="mvpn", + doi="10.17487/RFC6037", + } + +@misc{rfc6038, + author="A. Morton and L. Ciavattone", + title="{Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features}", + howpublished="RFC 6038 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6038", + pages="1--18", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6038.txt", + key="RFC 6038", + abstract={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]}, + keywords="Testing, Performance, Metric", + doi="10.17487/RFC6038", + } + +@misc{rfc6039, + author="V. Manral and M. Bhatia and J. Jaeggli and R. White", + title="{Issues with Existing Cryptographic Protection Methods for Routing Protocols}", + howpublished="RFC 6039 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6039", + pages="1--21", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6039.txt", + key="RFC 6039", + abstract={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. 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. 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.}, + doi="10.17487/RFC6039", + } + +@misc{rfc6040, + author="B. Briscoe", + title="{Tunnelling of Explicit Congestion Notification}", + howpublished="RFC 6040 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6040", + pages="1--35", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6040.txt", + key="RFC 6040", + abstract={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 chan ges 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]}, + keywords="Congestion Control and Management, Congestion Notification, Information Security, Tunnelling, Encapsulation, Decapsulation, Protocol, ECN, IPsec", + doi="10.17487/RFC6040", + } + +@misc{rfc6041, + author="A. Crouch and H. Khosravi and A. {Doria (Ed.)} and X. Wang and K. Ogawa", + title="{Forwarding and Control Element Separation (ForCES) Applicability Statement}", + howpublished="RFC 6041 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6041", + pages="1--14", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6041.txt", + key="RFC 6041", + abstract={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.}, + keywords="Routing, Control Plane, Management, Protocol", + doi="10.17487/RFC6041", + } + +@misc{rfc6042, + author="A. Keromytis", + title="{Transport Layer Security (TLS) Authorization Using KeyNote}", + howpublished="RFC 6042 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6042", + pages="1--7", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6042.txt", + key="RFC 6042", + abstract={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.}, + keywords="trust management, authorization, access control, certificates", + doi="10.17487/RFC6042", + } + +@misc{rfc6043, + author="J. Mattsson and T. Tian", + title="{MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)}", + howpublished="RFC 6043 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6043", + pages="1--58", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6309", +url="https://www.rfc-editor.org/rfc/rfc6043.txt", + key="RFC 6043", + abstract={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.}, + keywords="MIKEY, MIKEY-TICKET, KMS, SRTP, IMS, key management, ticket", + doi="10.17487/RFC6043", + } + +@misc{rfc6044, + author="M. Mohali", + title="{Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6044 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6044", + pages="1--24", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7544", +url="https://www.rfc-editor.org/rfc/rfc6044.txt", + key="RFC 6044", + abstract={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. 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. 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 Standard s Track specification; it is published for informational purposes.}, + doi="10.17487/RFC6044", + } + +@misc{rfc6045, + author="K. Moriarty", + title="{Real-time Inter-network Defense (RID)}", + howpublished="RFC 6045 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6045", + pages="1--75", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6545", +url="https://www.rfc-editor.org/rfc/rfc6045.txt", + key="RFC 6045", + abstract={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. 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.}, + keywords="Coordinated Incident Response, CSIRT, CIRT, IODEF, Incident Object Exchange, Description Format", + doi="10.17487/RFC6045", + } + +@misc{rfc6046, + author="K. Moriarty and B. Trammell", + title="{Transport of Real-time Inter-network Defense (RID) Messages}", + howpublished="RFC 6046 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6046", + pages="1--7", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6546", +url="https://www.rfc-editor.org/rfc/rfc6046.txt", + key="RFC 6046", + abstract={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.}, + keywords="Coordinate Incident Response, CSIRT, CIRT, IODEF, Incident Object Exchange, Description Format", + doi="10.17487/RFC6046", + } + +@misc{rfc6047, + author="A. {Melnikov (Ed.)}", + title="{iCalendar Message-Based Interoperability Protocol (iMIP)}", + howpublished="RFC 6047 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6047", + pages="1--22", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6047.txt", + key="RFC 6047", + abstract={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]}, + keywords="IMIP], electronic mail, transport, itip, iCalendar Transport-independent Interoperability Protocol, iCalendar Object Model", + doi="10.17487/RFC6047", + } + +@misc{rfc6048, + author="J. Elie", + title="{Network News Transfer Protocol (NNTP) Additions to LIST Command}", + howpublished="RFC 6048 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6048", + pages="1--25", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6048.txt", + key="RFC 6048", + abstract={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. 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]}, + keywords="Usenet, NetNews, capabilities", + doi="10.17487/RFC6048", + } + +@misc{rfc6049, + author="A. Morton and E. Stephan", + title="{Spatial Composition of Metrics}", + howpublished="RFC 6049 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6049", + pages="1--29", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6248", +url="https://www.rfc-editor.org/rfc/rfc6049.txt", + key="RFC 6049", + abstract={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]}, + keywords="Performance, Measurement, IPPM", + doi="10.17487/RFC6049", + } + +@misc{rfc6050, + author="K. Drage", + title="{A Session Initiation Protocol (SIP) Extension for the Identification of Services}", + howpublished="RFC 6050 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6050", + pages="1--19", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6050.txt", + key="RFC 6050", + abstract={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. 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.}, + keywords="SIP, trust domain, service identifier", + doi="10.17487/RFC6050", + } + +@misc{rfc6051, + author="C. Perkins and T. Schierl", + title="{Rapid Synchronisation of RTP Flows}", + howpublished="RFC 6051 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6051", + pages="1--22", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6051.txt", + key="RFC 6051", + abstract={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. 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]}, + keywords="rtcp, rtp control protocol, mcu, multipoint conference units, ssm, source-specific multicast", + doi="10.17487/RFC6051", + } + +@misc{rfc6052, + author="C. Bao and C. Huitema and M. Bagnulo and M. Boucadair and X. Li", + title="{IPv6 Addressing of IPv4/IPv6 Translators}", + howpublished="RFC 6052 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6052", + pages="1--18", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6052.txt", + key="RFC 6052", + abstract={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]}, + keywords="address, prefix, transition, translation, NAT, NAT64, BEHAVE, stateless, stateful", + doi="10.17487/RFC6052", + } + +@misc{rfc6053, + author="E. Haleplidis and K. Ogawa and W. Wang and J. Hadi Salim", + title="{Implementation Report for Forwarding and Control Element Separation (ForCES)}", + howpublished="RFC 6053 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6053", + pages="1--34", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6984", +url="https://www.rfc-editor.org/rfc/rfc6053.txt", + key="RFC 6053", + abstract={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. 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.}, + keywords="Stream Control Transmission Protocol-based Transport Mapping Layer, SCTP TML, forces Model", + doi="10.17487/RFC6053", + } + +@misc{rfc6054, + author="D. McGrew and B. Weis", + title="{Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic}", + howpublished="RFC 6054 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6054", + pages="1--10", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6054.txt", + key="RFC 6054", + abstract={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]}, + keywords="", + doi="10.17487/RFC6054", + } + +@misc{rfc6055, + author="D. Thaler and J. Klensin and S. Cheshire", + title="{IAB Thoughts on Encodings for Internationalized Domain Names}", + howpublished="RFC 6055 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6055", + pages="1--24", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6055.txt", + key="RFC 6055", + abstract={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.}, + keywords="Unicode, UTF-8,", + doi="10.17487/RFC6055", + } + +@misc{rfc6056, + author="M. Larsen and F. Gont", + title="{Recommendations for Transport-Protocol Port Randomization}", + howpublished="RFC 6056 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6056", + pages="1--29", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6056.txt", + key="RFC 6056", + abstract={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 documen t 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.}, + keywords="tcp, transmission control protocl, blind attacks", + doi="10.17487/RFC6056", + } + +@misc{rfc6057, + author="C. Bastian and T. Klieber and J. Livingood and J. Mills and R. Woundy", + title="{Comcast's Protocol-Agnostic Congestion Management System}", + howpublished="RFC 6057 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6057", + pages="1--29", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6057.txt", + key="RFC 6057", + abstract={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.}, + keywords="ISP, Internet Service Provider, Network Management", + doi="10.17487/RFC6057", + } + +@misc{rfc6058, + author="M. {Liebsch (Ed.)} and A. Muhanna and O. Blume", + title="{Transient Binding for Proxy Mobile IPv6}", + howpublished="RFC 6058 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6058", + pages="1--35", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6058.txt", + key="RFC 6058", + abstract={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.}, + keywords="PMIP, handover optimization, handover delay, tBCE, late path switch, forwarding, make-before-break, dual radio handover, single radio handover, transient binding cache entry", + doi="10.17487/RFC6058", + } + +@misc{rfc6059, + author="S. Krishnan and G. Daley", + title="{Simple Procedures for Detecting Network Attachment in IPv6}", + howpublished="RFC 6059 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6059", + pages="1--19", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6059.txt", + key="RFC 6059", + abstract={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]}, + keywords="DNA, DNAv6, ND, IPv6 neighbor discovery, neighbor discovery, send, secure neighbor discovery, DHCPv6, stateless autoconfiguration, change detection, movement detection, DNAv4, link detection, mobility", + doi="10.17487/RFC6059", + } + +@misc{rfc6060, + author="D. Fedyk and H. Shah and N. Bitar and A. Takacs", + title="{Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)}", + howpublished="RFC 6060 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6060", + pages="1--20", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6060.txt", + key="RFC 6060", + abstract={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]}, + keywords="IEEE data plane", + doi="10.17487/RFC6060", + } + +@misc{rfc6061, + author="B. Rosen", + title="{Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)}", + howpublished="RFC 6061 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6061", + pages="1--7", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6061.txt", + key="RFC 6061", + abstract={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.}, + doi="10.17487/RFC6061", + } + +@misc{rfc6062, + author="S. {Perreault (Ed.)} and J. Rosenberg", + title="{Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations}", + howpublished="RFC 6062 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6062", + pages="1--13", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6062.txt", + key="RFC 6062", + abstract={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]}, + keywords="NAT, TURN, STUN", + doi="10.17487/RFC6062", + } + +@misc{rfc6063, + author="A. Doherty and M. Pei and S. Machani and M. Nystrom", + title="{Dynamic Symmetric Key Provisioning Protocol (DSKPP)}", + howpublished="RFC 6063 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6063", + pages="1--105", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6063.txt", + key="RFC 6063", + abstract={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. 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]}, + keywords="Cryptographic module, Cryptographic Token, key initialization, credentials, online provisioning", + doi="10.17487/RFC6063", + } + +@misc{rfc6064, + author="M. Westerlund and P. Frojdh", + title="{SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service}", + howpublished="RFC 6064 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6064", + pages="1--22", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6064.txt", + key="RFC 6064", + abstract={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.}, + keywords="3GPP, PSS, MBMS, SDP, RTSP, IANA", + doi="10.17487/RFC6064", + } + +@misc{rfc6065, + author="K. Narayan and D. Nelson and R. {Presuhn (Ed.)}", + title="{Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings}", + howpublished="RFC 6065 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6065", + pages="1--19", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6065.txt", + key="RFC 6065", + abstract={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]}, + keywords="Network Management, Security, Management Information Base, MIB, SMIv2, RADIUS, AAA, VACM", + doi="10.17487/RFC6065", + } + +@misc{rfc6066, + author="D. {Eastlake 3rd}", + title="{Transport Layer Security (TLS) Extensions: Extension Definitions}", + howpublished="RFC 6066 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6066", + pages="1--25", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 8446, 8449", +url="https://www.rfc-editor.org/rfc/rfc6066.txt", + key="RFC 6066", + abstract={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]}, + keywords="server\_name, max\_fragment\_length, client\_certificate\_url, trusted\_ca\_keys, truncated\_hmac, status\_request", + doi="10.17487/RFC6066", + } + +@misc{rfc6067, + author="M. Davis and A. Phillips and Y. Umaoka", + title="{BCP 47 Extension U}", + howpublished="RFC 6067 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6067", + pages="1--8", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6067.txt", + key="RFC 6067", + abstract={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.}, + keywords="locale, bcp 47", + doi="10.17487/RFC6067", + } + +@misc{rfc6068, + author="M. Duerst and L. Masinter and J. Zawinski", + title="{The 'mailto' URI Scheme}", + howpublished="RFC 6068 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6068", + pages="1--17", + year=2010, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6068.txt", + key="RFC 6068", + abstract={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]}, + keywords="mailto, email address, URI scheme, IRI", + doi="10.17487/RFC6068", + } + +@misc{rfc6069, + author="A. Zimmermann and A. Hannemann", + title="{Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)}", + howpublished="RFC 6069 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6069", + pages="1--23", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6069.txt", + key="RFC 6069", + abstract={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. 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.}, + keywords="Internet Control Message Protocol (ICMP), Retranmission Timeout (RTO)", + doi="10.17487/RFC6069", + } + +@misc{rfc6070, + author="S. Josefsson", + title="{PKCS \#5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors}", + howpublished="RFC 6070 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6070", + pages="1--5", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6070.txt", + key="RFC 6070", + abstract={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.}, + doi="10.17487/RFC6070", + } + +@misc{rfc6071, + author="S. Frankel and S. Krishnan", + title="{IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap}", + howpublished="RFC 6071 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6071", + pages="1--63", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6071.txt", + key="RFC 6071", + abstract={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. 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.'' 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.}, + keywords="internet protocol, privacy, authentication", + doi="10.17487/RFC6071", + } + +@misc{rfc6072, + author="C. Jennings and J. {Fischl (Ed.)}", + title="{Certificate Management Service for the Session Initiation Protocol (SIP)}", + howpublished="RFC 6072 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6072", + pages="1--30", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6072.txt", + key="RFC 6072", + abstract={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]}, + keywords="credential service, aor, address of record", + doi="10.17487/RFC6072", + } + +@misc{rfc6073, + author="L. Martini and C. Metz and T. Nadeau and M. Bocci and M. Aissaoui", + title="{Segmented Pseudowire}", + howpublished="RFC 6073 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6073", + pages="1--43", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6723, 7267", +url="https://www.rfc-editor.org/rfc/rfc6073.txt", + key="RFC 6073", + abstract={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]}, + keywords="pws, psn, packet switched network, pw control plane domain", + doi="10.17487/RFC6073", + } + +@misc{rfc6074, + author="E. Rosen and B. Davie and V. Radoaca and W. Luo", + title="{Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)}", + howpublished="RFC 6074 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6074", + pages="1--32", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6074.txt", + key="RFC 6074", + abstract={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- T RACK]}, + keywords="", + doi="10.17487/RFC6074", + } + +@misc{rfc6075, + author="D. Cridland", + title="{The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry}", + howpublished="RFC 6075 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6075", + pages="1--7", + year=2010, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6075.txt", + key="RFC 6075", + abstract={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]}, + keywords="annotate, metadata", + doi="10.17487/RFC6075", + } + +@misc{rfc6076, + author="D. Malas and A. Morton", + title="{Basic Telephony SIP End-to-End Performance Metrics}", + howpublished="RFC 6076 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6076", + pages="1--27", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6076.txt", + key="RFC 6076", + abstract={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]}, + keywords="Benchmarking, Lab, Test, Time, Measurement, Service, Session, Protocol", + doi="10.17487/RFC6076", + } + +@misc{rfc6077, + author="D. {Papadimitriou (Ed.)} and M. Welzl and M. Scharf and B. Briscoe", + title="{Open Research Issues in Internet Congestion Control}", + howpublished="RFC 6077 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6077", + pages="1--51", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6077.txt", + key="RFC 6077", + abstract={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.}, + keywords="Signalling, Performance, Robustness, Fairness, Stability, Misbehaviour, Architecture", + doi="10.17487/RFC6077", + } + +@misc{rfc6078, + author="G. Camarillo and J. Melen", + title="{Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)}", + howpublished="RFC 6078 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6078", + pages="1--17", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6078.txt", + key="RFC 6078", + abstract={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.}, + keywords="HIP DATA", + doi="10.17487/RFC6078", + } + +@misc{rfc6079, + author="G. Camarillo and P. Nikander and J. Hautakorpi and A. Keranen and A. Johnston", + title="{HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)}", + howpublished="RFC 6079 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6079", + pages="1--21", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6079.txt", + key="RFC 6079", + abstract={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.}, + doi="10.17487/RFC6079", + } + +@misc{rfc6080, + author="D. Petrie and S. {Channabasappa (Ed.)}", + title="{A Framework for Session Initiation Protocol User Agent Profile Delivery}", + howpublished="RFC 6080 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6080", + pages="1--54", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6080.txt", + key="RFC 6080", + abstract={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]}, + keywords="SIP, Configuration, Framework, User Agent, profile", + doi="10.17487/RFC6080", + } + +@misc{rfc6081, + author="D. Thaler", + title="{Teredo Extensions}", + howpublished="RFC 6081 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6081", + pages="1--59", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6081.txt", + key="RFC 6081", + abstract={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]}, + keywords="IPv6, NAT, traversal, transition, translation, translator", + doi="10.17487/RFC6081", + } + +@misc{rfc6082, + author="K. Whistler and G. Adams and M. Duerst and R. {Presuhn (Ed.)} and J. Klensin", + title="{Deprecating Unicode Language Tag Characters: RFC 2482 is Historic}", + howpublished="RFC 6082 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6082", + pages="1--4", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6082.txt", + key="RFC 6082", + abstract={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.}, + keywords="characters, strings, ASCII", + doi="10.17487/RFC6082", + } + +@misc{rfc6083, + author="M. Tuexen and R. Seggelmann and E. Rescorla", + title="{Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)}", + howpublished="RFC 6083 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6083", + pages="1--9", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6083.txt", + key="RFC 6083", + abstract={This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). 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. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC6083", + } + +@misc{rfc6084, + author="X. Fu and C. Dickmann and J. Crowcroft", + title="{General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 6084 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6084", + pages="1--12", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6084.txt", + key="RFC 6084", + abstract={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.}, + keywords="Multihoming, Signaling, Partial Reliability", + doi="10.17487/RFC6084", + } + +@misc{rfc6085, + author="S. Gundavelli and M. Townsley and O. Troan and W. Dec", + title="{Address Mapping of IPv6 Multicast Packets on Ethernet}", + howpublished="RFC 6085 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6085", + pages="1--3", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6085.txt", + key="RFC 6085", + abstract={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]}, + keywords="", + doi="10.17487/RFC6085", + } + +@misc{rfc6086, + author="C. Holmberg and E. Burger and H. Kaplan", + title="{Session Initiation Protocol (SIP) INFO Method and Package Framework}", + howpublished="RFC 6086 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6086", + pages="1--36", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6086.txt", + key="RFC 6086", + abstract={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]}, + keywords="Info Package, Info-Package, Recv-Info", + doi="10.17487/RFC6086", + } + +@misc{rfc6087, + author="A. Bierman", + title="{Guidelines for Authors and Reviewers of YANG Data Model Documents}", + howpublished="RFC 6087 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6087", + pages="1--26", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6087.txt", + key="RFC 6087", + abstract={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.}, + keywords="NETMOD, NETCONF, XML, YANG", + doi="10.17487/RFC6087", + } + +@misc{rfc6088, + author="G. Tsirtsis and G. Giarreta and H. Soliman and N. Montavont", + title="{Traffic Selectors for Flow Bindings}", + howpublished="RFC 6088 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6088", + pages="1--13", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6088.txt", + key="RFC 6088", + abstract={This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK]}, + keywords="Mobile IPv6, Binary Traffic Selectors", + doi="10.17487/RFC6088", + } + +@misc{rfc6089, + author="G. Tsirtsis and H. Soliman and N. Montavont and G. Giaretta and K. Kuladinithi", + title="{Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support}", + howpublished="RFC 6089 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6089", + pages="1--31", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6089.txt", + key="RFC 6089", + abstract={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]}, + keywords="Flow Identification, Flow Summary, Binding Reference, Traffic Selector, Flow Binding Entry", + doi="10.17487/RFC6089", + } + +@misc{rfc6090, + author="D. McGrew and K. Igoe and M. Salter", + title="{Fundamental Elliptic Curve Cryptography Algorithms}", + howpublished="RFC 6090 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6090", + pages="1--34", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6090.txt", + key="RFC 6090", + abstract={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.}, + keywords="ECC", + doi="10.17487/RFC6090", + } + +@misc{rfc6091, + author="N. Mavrogiannopoulos and D. Gillmor", + title="{Using OpenPGP Keys for Transport Layer Security (TLS) Authentication}", + howpublished="RFC 6091 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6091", + pages="1--9", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6091.txt", + key="RFC 6091", + abstract={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.}, + keywords="Certificate type negotiation, tls handshake protocol, handshake", + doi="10.17487/RFC6091", + } + +@misc{rfc6092, + author="J. {Woodyatt (Ed.)}", + title="{Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service}", + howpublished="RFC 6092 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6092", + pages="1--36", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6092.txt", + key="RFC 6092", + abstract={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.}, + keywords="cpe, firewall, filter", + doi="10.17487/RFC6092", + } + +@misc{rfc6093, + author="F. Gont and A. Yourtchenko", + title="{On the Implementation of the TCP Urgent Mechanism}", + howpublished="RFC 6093 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6093", + pages="1--12", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6093.txt", + key="RFC 6093", + abstract={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]}, + keywords="Transmission Control Protocol", + doi="10.17487/RFC6093", + } + +@misc{rfc6094, + author="M. Bhatia and V. Manral", + title="{Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols}", + howpublished="RFC 6094 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6094", + pages="1--11", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6094.txt", + key="RFC 6094", + abstract={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. 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. Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets. This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptograph ic 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.}, + keywords="IGP security", + doi="10.17487/RFC6094", + } + +@misc{rfc6095, + author="B. Linowski and M. Ersue and S. Kuryla", + title="{Extending YANG with Language Abstractions}", + howpublished="RFC 6095 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6095", + pages="1--75", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6095.txt", + key="RFC 6095", + abstract={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.}, + keywords="YANG, model, complex-type, Complex Types, Typed Instance, Resource Model, Inheritance, class", + doi="10.17487/RFC6095", + } + +@misc{rfc6096, + author="M. Tuexen and R. Stewart", + title="{Stream Control Transmission Protocol (SCTP) Chunk Flags Registration}", + howpublished="RFC 6096 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6096", + pages="1--8", + year=2011, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6096.txt", + key="RFC 6096", + abstract={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]}, + keywords="", + doi="10.17487/RFC6096", + } + +@misc{rfc6097, + author="J. Korhonen and V. Devarapalli", + title="{Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6}", + howpublished="RFC 6097 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6097", + pages="1--10", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6097.txt", + key="RFC 6097", + abstract={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.}, + keywords="PMIPv6, 3GPP, DNS, AAA", + doi="10.17487/RFC6097", + } + +@misc{rfc6098, + author="H. Deng and H. Levkowetz and V. Devarapalli and S. Gundavelli and B. Haley", + title="{Generic Notification Message for Mobile IPv4}", + howpublished="RFC 6098 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6098", + pages="1--33", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6098.txt", + key="RFC 6098", + abstract={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]}, + keywords="mipv4", + doi="10.17487/RFC6098", + } + +@misc{rfc6101, + author="A. Freier and P. Karlton and P. Kocher", + title="{The Secure Sockets Layer (SSL) Protocol Version 3.0}", + howpublished="RFC 6101 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6101", + pages="1--67", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6101.txt", + key="RFC 6101", + abstract={This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows. 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.}, + keywords="Transport layer security", + doi="10.17487/RFC6101", + } + +@misc{rfc6104, + author="T. Chown and S. Venaas", + title="{Rogue IPv6 Router Advertisement Problem Statement}", + howpublished="RFC 6104 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6104", + pages="1--16", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6104.txt", + key="RFC 6104", + abstract={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.}, + keywords="RA, rogue ra", + doi="10.17487/RFC6104", + } + +@misc{rfc6105, + author="E. Levy-Abegnoli and G. Van de Velde and C. Popoviciu and J. Mohacsi", + title="{IPv6 Router Advertisement Guard}", + howpublished="RFC 6105 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6105", + pages="1--10", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7113", +url="https://www.rfc-editor.org/rfc/rfc6105.txt", + key="RFC 6105", + abstract={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.}, + keywords="SEcure Neighbor Discovery, Stateless Address Autoconfiguration", + doi="10.17487/RFC6105", + } + +@misc{rfc6106, + author="J. Jeong and S. Park and L. Beloeil and S. Madanapalli", + title="{IPv6 Router Advertisement Options for DNS Configuration}", + howpublished="RFC 6106 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6106", + pages="1--19", + year=2010, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8106", +url="https://www.rfc-editor.org/rfc/rfc6106.txt", + key="RFC 6106", + abstract={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]}, + keywords="DNS Service, DNS Option, Recursive DNS Server Address, DNS Search List, Stateless Autoconfiguration", + doi="10.17487/RFC6106", + } + +@misc{rfc6107, + author="K. {Shiomoto (Ed.)} and A. {Farrel (Ed.)}", + title="{Procedures for Dynamically Signaled Hierarchical Label Switched Paths}", + howpublished="RFC 6107 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6107", + pages="1--30", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6107.txt", + key="RFC 6107", + abstract={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. 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]}, + keywords="TE links, Bundled links, GMPLS, dynamically provisioned networks", + doi="10.17487/RFC6107", + } + +@misc{rfc6108, + author="C. Chung and A. Kasyanov and J. Livingood and N. Mody and B. Van Lieu", + title="{Comcast's Web Notification System Design}", + howpublished="RFC 6108 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6108", + pages="1--24", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6108.txt", + key="RFC 6108", + abstract={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.}, + keywords="ISP, Internet Service Provider, bot remediation, bot notification", + doi="10.17487/RFC6108", + } + +@misc{rfc6109, + author="C. Petrucci and F. Gennai and A. Shahin and A. Vinciarelli", + title="{La Posta Elettronica Certificata - Italian Certified Electronic Mail}", + howpublished="RFC 6109 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6109", + pages="1--65", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6109.txt", + key="RFC 6109", + abstract={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. 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 w ritten based upon the Italian Law DPR. November 2, 2005. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + keywords="PEC, Registered mail, Return receipt, Digitally signed email, Digitally signed notification, MIME, SMIME", + doi="10.17487/RFC6109", + } + +@misc{rfc6110, + author="L. {Lhotka (Ed.)}", + title="{Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content}", + howpublished="RFC 6110 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6110", + pages="1--100", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7952", +url="https://www.rfc-editor.org/rfc/rfc6110.txt", + key="RFC 6110", + abstract={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]}, + keywords="DSDL, validation, RELAX NG, Schematron, DSRL", + doi="10.17487/RFC6110", + } + +@misc{rfc6111, + author="L. Zhu", + title="{Additional Kerberos Naming Constraints}", + howpublished="RFC 6111 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6111", + pages="1--6", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6111.txt", + key="RFC 6111", + abstract={This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK]}, + keywords="principal names, realm names", + doi="10.17487/RFC6111", + } + +@misc{rfc6112, + author="L. Zhu and P. Leach and S. Hartman", + title="{Anonymity Support for Kerberos}", + howpublished="RFC 6112 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6112", + pages="1--16", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8062", +url="https://www.rfc-editor.org/rfc/rfc6112.txt", + key="RFC 6112", + abstract={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]}, + keywords="kerberos realm", + doi="10.17487/RFC6112", + } + +@misc{rfc6113, + author="S. Hartman and L. Zhu", + title="{A Generalized Framework for Kerberos Pre-Authentication}", + howpublished="RFC 6113 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6113", + pages="1--48", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6113.txt", + key="RFC 6113", + abstract={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. 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. 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]}, + keywords="", + doi="10.17487/RFC6113", + } + +@misc{rfc6114, + author="M. Katagi and S. Moriai", + title="{The 128-Bit Blockcipher CLEFIA}", + howpublished="RFC 6114 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6114", + pages="1--33", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6114.txt", + key="RFC 6114", + abstract={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.}, + keywords="security, lightweight cryptography, encryption algorithm", + doi="10.17487/RFC6114", + } + +@misc{rfc6115, + author="T. {Li (Ed.)}", + title="{Recommendation for a Routing Architecture}", + howpublished="RFC 6115 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6115", + pages="1--73", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6115.txt", + key="RFC 6115", + abstract={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.}, + doi="10.17487/RFC6115", + } + +@misc{rfc6116, + author="S. Bradner and L. Conroy and K. Fujiwara", + title="{The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)}", + howpublished="RFC 6116 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6116", + pages="1--22", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6116.txt", + key="RFC 6116", + abstract={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]}, + keywords="DNS, E.164, NAPTR, dynamic delegation discovery system, e164.arpa", + doi="10.17487/RFC6116", + } + +@misc{rfc6117, + author="B. Hoeneisen and A. Mayrhofer and J. Livingood", + title="{IANA Registration of Enumservices: Guide, Template, and IANA Considerations}", + howpublished="RFC 6117 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6117", + pages="1--40", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6117.txt", + key="RFC 6117", + abstract={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]}, + keywords="domain name system", + doi="10.17487/RFC6117", + } + +@misc{rfc6118, + author="B. Hoeneisen and A. Mayrhofer", + title="{Update of Legacy IANA Registrations of Enumservices}", + howpublished="RFC 6118 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6118", + pages="1--68", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6118.txt", + key="RFC 6118", + abstract={This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. [STANDARDS-TRACK]}, + keywords="domain name system", + doi="10.17487/RFC6118", + } + +@misc{rfc6119, + author="J. Harrison and J. Berger and M. Bartlett", + title="{IPv6 Traffic Engineering in IS-IS}", + howpublished="RFC 6119 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6119", + pages="1--10", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6119.txt", + key="RFC 6119", + abstract={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]}, + keywords="", + doi="10.17487/RFC6119", + } + +@misc{rfc6120, + author="P. Saint-Andre", + title="{Extensible Messaging and Presence Protocol (XMPP): Core}", + howpublished="RFC 6120 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6120", + pages="1--211", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7590", +url="https://www.rfc-editor.org/rfc/rfc6120.txt", + key="RFC 6120", + abstract={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]}, + keywords="XMPP, Extensible Messaging and Presence Protocol, Jabber, Messaging, Instant Messaging, Presence, Extensible Markup Language, XML", + doi="10.17487/RFC6120", + } + +@misc{rfc6121, + author="P. Saint-Andre", + title="{Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence}", + howpublished="RFC 6121 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6121", + pages="1--114", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6121.txt", + key="RFC 6121", + abstract={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]}, + keywords="XMPP, Extensible Messaging and Presence Protocol, Jabber, IM, Instant Messaging, Presence, XML, Extensible Markup Language", + doi="10.17487/RFC6121", + } + +@misc{rfc6122, + author="P. Saint-Andre", + title="{Extensible Messaging and Presence Protocol (XMPP): Address Format}", + howpublished="RFC 6122 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6122", + pages="1--23", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7622", +url="https://www.rfc-editor.org/rfc/rfc6122.txt", + key="RFC 6122", + abstract={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]}, + keywords="XMPP, Jabber, Messaging, Instant Messaging, Presence, Extensible Markup Language, XML", + doi="10.17487/RFC6122", + } + +@misc{rfc6123, + author="A. Farrel", + title="{Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts}", + howpublished="RFC 6123 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6123", + pages="1--13", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6123.txt", + key="RFC 6123", + abstract={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. 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. 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.}, + doi="10.17487/RFC6123", + } + +@misc{rfc6124, + author="Y. Sheffer and G. Zorn and H. Tschofenig and S. Fluhrer", + title="{An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol}", + howpublished="RFC 6124 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6124", + pages="1--33", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6124.txt", + key="RFC 6124", + abstract={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.}, + keywords="password-based authentication, mutual authentication, password-based cryptography, password authenticated key exchange, weak password authentication", + doi="10.17487/RFC6124", + } + +@misc{rfc6125, + author="P. Saint-Andre and J. Hodges", + 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)}", + howpublished="RFC 6125 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6125", + pages="1--57", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6125.txt", + key="RFC 6125", + abstract={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]}, + keywords="", + doi="10.17487/RFC6125", + } + +@misc{rfc6126, + author="J. Chroboczek", + title="{The Babel Routing Protocol}", + howpublished="RFC 6126 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6126", + pages="1--45", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7298, 7557", +url="https://www.rfc-editor.org/rfc/rfc6126.txt", + key="RFC 6126", + abstract={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.}, + doi="10.17487/RFC6126", + } + +@misc{rfc6127, + author="J. Arkko and M. Townsley", + title="{IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios}", + howpublished="RFC 6127 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6127", + pages="1--20", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6127.txt", + key="RFC 6127", + abstract={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. 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.}, + keywords="address depletion, translation, NAT-PT, dual-stack, Softwire, Behave, NAT, NAT444", + doi="10.17487/RFC6127", + } + +@misc{rfc6128, + author="A. Begen", + title="{RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions}", + howpublished="RFC 6128 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6128", + pages="1--6", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6128.txt", + key="RFC 6128", + abstract={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]}, + keywords="", + doi="10.17487/RFC6128", + } + +@misc{rfc6129, + author="L. Romary and S. Lundberg", + title="{The 'application/tei+xml' Media Type}", + howpublished="RFC 6129 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6129", + pages="1--8", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6129.txt", + key="RFC 6129", + abstract={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.}, + keywords="Text Encoding Initiative, xml, text encoding, text representation, MIME type", + doi="10.17487/RFC6129", + } + +@misc{rfc6130, + author="T. Clausen and C. Dearlove and J. Dean", + title="{Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)}", + howpublished="RFC 6130 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6130", + pages="1--88", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7183, 7188, 7466", +url="https://www.rfc-editor.org/rfc/rfc6130.txt", + key="RFC 6130", + abstract={This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK]}, + keywords="MANET, OLSRv2, packetbb, Routing Protocol, NHDP, ad hoc network, bi-directional, 2-hop discovery, Wireless, SMF", + doi="10.17487/RFC6130", + } + +@misc{rfc6131, + author="R. George and B. Leiba", + title="{Sieve Vacation Extension: ``Seconds'' Parameter}", + howpublished="RFC 6131 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6131", + pages="1--5", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6131.txt", + key="RFC 6131", + abstract={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]}, + keywords="email, filters, auto-replies", + doi="10.17487/RFC6131", + } + +@misc{rfc6132, + author="R. George and B. Leiba", + title="{Sieve Notification Using Presence Information}", + howpublished="RFC 6132 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6132", + pages="1--8", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6132.txt", + key="RFC 6132", + abstract={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]}, + keywords="email, filters, context, status", + doi="10.17487/RFC6132", + } + +@misc{rfc6133, + author="R. George and B. Leiba and A. Melnikov", + title="{Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality}", + howpublished="RFC 6133 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6133", + pages="1--9", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6133.txt", + key="RFC 6133", + abstract={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.}, + doi="10.17487/RFC6133", + } + +@misc{rfc6134, + author="A. Melnikov and B. Leiba", + title="{Sieve Extension: Externally Stored Lists}", + howpublished="RFC 6134 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6134", + pages="1--18", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6134.txt", + key="RFC 6134", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC6134", + } + +@misc{rfc6135, + author="C. Holmberg and S. Blau", + title="{An Alternative Connection Model for the Message Session Relay Protocol (MSRP)}", + howpublished="RFC 6135 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6135", + pages="1--8", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6135.txt", + key="RFC 6135", + abstract={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]}, + keywords="comedia, comedia-tls, relay, SBC", + doi="10.17487/RFC6135", + } + +@misc{rfc6136, + author="A. {Sajassi (Ed.)} and D. {Mohan (Ed.)}", + title="{Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework}", + howpublished="RFC 6136 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6136", + pages="1--42", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6136.txt", + key="RFC 6136", + abstract={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.}, + doi="10.17487/RFC6136", + } + +@misc{rfc6137, + author="D. {Zisiadis (Ed.)} and S. {Kopsidas (Ed.)} and M. {Tsavli (Ed.)} and G. {Cessieux (Ed.)}", + title="{The Network Trouble Ticket Data Model (NTTDM)}", + howpublished="RFC 6137 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6137", + pages="1--46", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6137.txt", + key="RFC 6137", + abstract={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. 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 inci dents, 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.}, + keywords="Grid, Management, EGEE", + doi="10.17487/RFC6137", + } + +@misc{rfc6138, + author="S. {Kini (Ed.)} and W. {Lu (Ed.)}", + title="{LDP IGP Synchronization for Broadcast Networks}", + howpublished="RFC 6138 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6138", + pages="1--9", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6138.txt", + key="RFC 6138", + abstract={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.}, + doi="10.17487/RFC6138", + } + +@misc{rfc6139, + author="S. {Russert (Ed.)} and E. {Fleischman (Ed.)} and F. {Templin (Ed.)}", + title="{Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios}", + howpublished="RFC 6139 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6139", + pages="1--39", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6139.txt", + key="RFC 6139", + abstract={``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.}, + keywords="Encapsulation, Tunnel, Architecture, Scalability, Mobility, MANET, Security, IPv6, Aerospace, IRON, VET, SEAL, ISATAP", + doi="10.17487/RFC6139", + } + +@misc{rfc6140, + author="A.B. Roach", + title="{Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6140 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6140", + pages="1--35", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6140.txt", + key="RFC 6140", + abstract={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]}, + keywords="Bulk Registration, Implicit Registration, GIN, PBX, SSP, SIP-PBX", + doi="10.17487/RFC6140", + } + +@misc{rfc6141, + author="G. {Camarillo (Ed.)} and C. Holmberg and Y. Gao", + title="{Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6141 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6141", + pages="1--26", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6141.txt", + key="RFC 6141", + abstract={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]}, + keywords="re-INVITE, offer/answer, rollback", + doi="10.17487/RFC6141", + } + +@misc{rfc6142, + author="A. Moise and J. Brodkin", + title="{ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP}", + howpublished="RFC 6142 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6142", + pages="1--26", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6142.txt", + key="RFC 6142", + abstract={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. 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.}, + keywords="Advanced Metering Infrastructure, ami, application layer message", + doi="10.17487/RFC6142", + } + +@misc{rfc6143, + author="T. Richardson and J. Levine", + title="{The Remote Framebuffer Protocol}", + howpublished="RFC 6143 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6143", + pages="1--39", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6143.txt", + key="RFC 6143", + abstract={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.}, + keywords="vnc, rfb, remote framebuffer, remote GUI", + doi="10.17487/RFC6143", + } + +@misc{rfc6144, + author="F. Baker and X. Li and C. Bao and K. Yin", + title="{Framework for IPv4/IPv6 Translation}", + howpublished="RFC 6144 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6144", + pages="1--31", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6144.txt", + key="RFC 6144", + abstract={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.}, + keywords="stateless translation, stateful translation", + doi="10.17487/RFC6144", + } + +@misc{rfc6145, + author="X. Li and C. Bao and F. Baker", + title="{IP/ICMP Translation Algorithm}", + howpublished="RFC 6145 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6145", + pages="1--33", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7915, updated by RFCs 6791, 7757", +url="https://www.rfc-editor.org/rfc/rfc6145.txt", + key="RFC 6145", + abstract={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]}, + keywords="SIIT], internet, protocol, control, message, IPv4, IPv6, Stateless IP/ICMP Translation Algorithm,", + doi="10.17487/RFC6145", + } + +@misc{rfc6146, + author="M. Bagnulo and P. Matthews and I. van Beijnum", + title="{Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers}", + howpublished="RFC 6146 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6146", + pages="1--45", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6146.txt", + key="RFC 6146", + keywords="NAT64, IPv6", + doi="10.17487/RFC6146", + } + +@misc{rfc6147, + author="M. Bagnulo and A. Sullivan and P. Matthews and I. van Beijnum", + title="{DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers}", + howpublished="RFC 6147 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6147", + pages="1--32", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6147.txt", + key="RFC 6147", + abstract={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]}, + keywords="AAAA", + doi="10.17487/RFC6147", + } + +@misc{rfc6148, + author="P. Kurapati and R. Desetti and B. Joshi", + title="{DHCPv4 Lease Query by Relay Agent Remote ID}", + howpublished="RFC 6148 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6148", + pages="1--13", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6148.txt", + key="RFC 6148", + abstract={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]}, + keywords="dynamic host configuration protocol", + doi="10.17487/RFC6148", + } + +@misc{rfc6149, + author="S. Turner and L. Chen", + title="{MD2 to Historic Status}", + howpublished="RFC 6149 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6149", + pages="1--7", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6149.txt", + key="RFC 6149", + abstract={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.}, + keywords="security, encryption, signature", + doi="10.17487/RFC6149", + } + +@misc{rfc6150, + author="S. Turner and L. Chen", + title="{MD4 to Historic Status}", + howpublished="RFC 6150 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6150", + pages="1--10", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6150.txt", + key="RFC 6150", + abstract={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.}, + keywords="MD4, security, encryption, signature", + doi="10.17487/RFC6150", + } + +@misc{rfc6151, + author="S. Turner and L. Chen", + title="{Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms}", + howpublished="RFC 6151 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6151", + pages="1--7", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6151.txt", + key="RFC 6151", + abstract={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.}, + keywords="signature, eneryption, ipsec, Message Digest, encryption", + doi="10.17487/RFC6151", + } + +@misc{rfc6152, + author="J. Klensin and N. Freed and M. Rose and D. {Crocker (Ed.)}", + title="{SMTP Service Extension for 8-bit MIME Transport}", + howpublished="RFC 6152 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="6152", + pages="1--7", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6152.txt", + key="RFC 6152", + abstract={This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]}, + keywords="simple mail transfer", + doi="10.17487/RFC6152", + } + +@misc{rfc6153, + author="S. Das and G. Bajko", + title="{DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery}", + howpublished="RFC 6153 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6153", + pages="1--7", + year=2011, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6153.txt", + key="RFC 6153", + abstract={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]}, + keywords="Dynamic Host Configuration Protocol", + doi="10.17487/RFC6153", + } + +@misc{rfc6154, + author="B. Leiba and J. Nicolson", + title="{IMAP LIST Extension for Special-Use Mailboxes}", + howpublished="RFC 6154 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6154", + pages="1--12", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6154.txt", + key="RFC 6154", + abstract={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]}, + keywords="IMAP, email", + doi="10.17487/RFC6154", + } + +@misc{rfc6155, + author="J. Winterbottom and M. Thomson and H. Tschofenig and R. Barnes", + title="{Use of Device Identity in HTTP-Enabled Location Delivery (HELD)}", + howpublished="RFC 6155 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6155", + pages="1--27", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6915", +url="https://www.rfc-editor.org/rfc/rfc6155.txt", + key="RFC 6155", + abstract={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. 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. 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]}, + keywords="", + doi="10.17487/RFC6155", + } + +@misc{rfc6156, + author="G. Camarillo and O. Novo and S. {Perreault (Ed.)}", + title="{Traversal Using Relays around NAT (TURN) Extension for IPv6}", + howpublished="RFC 6156 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6156", + pages="1--14", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6156.txt", + key="RFC 6156", + abstract={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]}, + keywords="STUN, TURN, IPv6", + doi="10.17487/RFC6156", + } + +@misc{rfc6157, + author="G. Camarillo and K. El Malki and V. Gurbani", + title="{IPv6 Transition in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6157 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6157", + pages="1--15", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6157.txt", + key="RFC 6157", + abstract={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]}, + keywords="", + doi="10.17487/RFC6157", + } + +@misc{rfc6158, + author="A. {DeKok (Ed.)} and G. Weber", + title="{RADIUS Design Guidelines}", + howpublished="RFC 6158 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6158", + pages="1--38", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6929, 8044", +url="https://www.rfc-editor.org/rfc/rfc6158.txt", + key="RFC 6158", + abstract={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.}, + keywords="", + doi="10.17487/RFC6158", + } + +@misc{rfc6159, + author="T. Tsou and G. Zorn and T. {Taylor (Ed.)}", + title="{Session-Specific Explicit Diameter Request Routing}", + howpublished="RFC 6159 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6159", + pages="1--19", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6159.txt", + key="RFC 6159", + abstract={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.}, + keywords="Diameter routing", + doi="10.17487/RFC6159", + } + +@misc{rfc6160, + author="S. Turner", + title="{Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types}", + howpublished="RFC 6160 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6160", + pages="1--5", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6160.txt", + key="RFC 6160", + abstract={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]}, + keywords="", + doi="10.17487/RFC6160", + } + +@misc{rfc6161, + author="S. Turner", + title="{Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type}", + howpublished="RFC 6161 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6161", + pages="1--3", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6161.txt", + key="RFC 6161", + abstract={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]}, + keywords="ecdsa, ecdh, EnvelopedData and Elliptic Curve Digital Signature Algorithm", + doi="10.17487/RFC6161", + } + +@misc{rfc6162, + author="S. Turner", + title="{Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type}", + howpublished="RFC 6162 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6162", + pages="1--4", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6162.txt", + key="RFC 6162", + abstract={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]}, + keywords="ecdsa, ecdh, EnvelopedData and Elliptic Curve Digital Signature Algorithm", + doi="10.17487/RFC6162", + } + +@misc{rfc6163, + author="Y. {Lee (Ed.)} and G. {Bernstein (Ed.)} and W. Imajuku", + title="{Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)}", + howpublished="RFC 6163 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6163", + pages="1--51", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6163.txt", + key="RFC 6163", + abstract={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. 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.}, + keywords="Generalized Multi-Protocol Label Switching, Routing and Wavelength Assignment, RWA", + doi="10.17487/RFC6163", + } + +@misc{rfc6164, + author="M. Kohno and B. Nitzan and R. Bush and Y. Matsuzaki and L. Colitti and T. Narten", + title="{Using 127-Bit IPv6 Prefixes on Inter-Router Links}", + howpublished="RFC 6164 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6164", + pages="1--8", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6547", +url="https://www.rfc-editor.org/rfc/rfc6164.txt", + key="RFC 6164", + abstract={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]}, + keywords="addressing, prefix length, security", + doi="10.17487/RFC6164", + } + +@misc{rfc6165, + author="A. Banerjee and D. Ward", + title="{Extensions to IS-IS for Layer-2 Systems}", + howpublished="RFC 6165 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6165", + pages="1--7", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6165.txt", + key="RFC 6165", + abstract={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]}, + keywords="Intermediate System to Intermediate System", + doi="10.17487/RFC6165", + } + +@misc{rfc6166, + author="S. Venaas", + title="{A Registry for PIM Message Types}", + howpublished="RFC 6166 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6166", + pages="1--4", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6166.txt", + key="RFC 6166", + abstract={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. In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]}, + keywords="IANA, Protocol Independent Multicast", + doi="10.17487/RFC6166", + } + +@misc{rfc6167, + author="M. Phillips and P. Adams and D. Rokicki and E. Johnson", + title="{URI Scheme for Java(tm) Message Service 1.0}", + howpublished="RFC 6167 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6167", + pages="1--22", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6167.txt", + key="RFC 6167", + abstract={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.}, + keywords="SOAP, JMS, JNDI, IRI", + doi="10.17487/RFC6167", + } + +@misc{rfc6168, + author="W. Hardaker", + title="{Requirements for Management of Name Servers for the DNS}", + howpublished="RFC 6168 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6168", + pages="1--17", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6168.txt", + key="RFC 6168", + abstract={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. 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.}, + keywords="DNS, Domain Name System, Management", + doi="10.17487/RFC6168", + } + +@misc{rfc6169, + author="S. Krishnan and D. Thaler and J. Hoagland", + title="{Security Concerns with IP Tunneling}", + howpublished="RFC 6169 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6169", + pages="1--20", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6169.txt", + key="RFC 6169", + abstract={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]}, + keywords="", + doi="10.17487/RFC6169", + } + +@misc{rfc6170, + author="S. Santesson and R. Housley and S. Bajaj and L. Rosenthol", + title="{Internet X.509 Public Key Infrastructure -- Certificate Image}", + howpublished="RFC 6170 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6170", + pages="1--12", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6170.txt", + key="RFC 6170", + abstract={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]}, + keywords="otherLogos", + doi="10.17487/RFC6170", + } + +@misc{rfc6171, + author="K. Zeilenga", + title="{The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control}", + howpublished="RFC 6171 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6171", + pages="1--6", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6171.txt", + key="RFC 6171", + abstract={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]}, + keywords="x.511, dontusecopy", + doi="10.17487/RFC6171", + } + +@misc{rfc6172, + author="D. Black and D. Peterson", + title="{Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode}", + howpublished="RFC 6172 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6172", + pages="1--6", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6172.txt", + key="RFC 6172", + abstract={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. iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document. 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]}, + keywords="FCIP", + doi="10.17487/RFC6172", + } + +@misc{rfc6173, + author="P. {Venkatesen (Ed.)}", + title="{Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)}", + howpublished="RFC 6173 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6173", + pages="1--31", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6173.txt", + key="RFC 6173", + abstract={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. This document obsoletes RFC 4369. [STANDARDS-TRACK]}, + keywords="Management Information Base, mib, IFCP-MGMT-MIB", + doi="10.17487/RFC6173", + } + +@misc{rfc6174, + author="E. Juskevicius", + title="{Definition of IETF Working Group Document States}", + howpublished="RFC 6174 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6174", + pages="1--25", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6174.txt", + key="RFC 6174", + abstract={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. 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.}, + keywords="WG I-D States, I-D Availability States", + doi="10.17487/RFC6174", + } + +@misc{rfc6175, + author="E. Juskevicius", + title="{Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors}", + howpublished="RFC 6175 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6175", + pages="1--23", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6175.txt", + key="RFC 6175", + abstract={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.}, + keywords="WG Document States, I-D States", + doi="10.17487/RFC6175", + } + +@misc{rfc6176, + author="S. Turner and T. Polk", + title="{Prohibiting Secure Sockets Layer (SSL) Version 2.0}", + howpublished="RFC 6176 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6176", + pages="1--4", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6176.txt", + key="RFC 6176", + abstract={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]}, + keywords="", + doi="10.17487/RFC6176", + } + +@misc{rfc6177, + author="T. Narten and G. Huston and L. Roberts", + title="{IPv6 Address Assignment to End Sites}", + howpublished="RFC 6177 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6177", + pages="1--9", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6177.txt", + key="RFC 6177", + abstract={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. This document obsoletes RFC 3177. [STANDARDS-TRACK]}, + keywords="internet architecture board, engineering steering group, protocol", + doi="10.17487/RFC6177", + } + +@misc{rfc6178, + author="D. Smith and J. Mullooly and W. Jaeger and T. Scholl", + title="{Label Edge Router Forwarding of IPv4 Option Packets}", + howpublished="RFC 6178 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6178", + pages="1--9", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6178.txt", + key="RFC 6178", + abstract={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]}, + keywords="FEC, MPLS, LER, Security, DoS", + doi="10.17487/RFC6178", + } + +@misc{rfc6179, + author="F. {Templin (Ed.)}", + title="{The Internet Routing Overlay Network (IRON)}", + howpublished="RFC 6179 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6179", + pages="1--37", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6179.txt", + key="RFC 6179", + abstract={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.}, + keywords="Encapsulation, Tunnel, Architecture, Scalability, Mobility, MANET, Security, Recursion, Addressing, Routing, IPv6, Aerospace, Aeronautics, Space, IRON, RANGER, VET, SEAL, ISATAP", + doi="10.17487/RFC6179", + } + +@misc{rfc6180, + author="J. Arkko and F. Baker", + title="{Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment}", + howpublished="RFC 6180 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6180", + pages="1--20", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6180.txt", + key="RFC 6180", + abstract={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.}, + doi="10.17487/RFC6180", + } + +@misc{rfc6181, + author="M. Bagnulo", + title="{Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses}", + howpublished="RFC 6181 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6181", + pages="1--17", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6181.txt", + key="RFC 6181", + abstract={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.}, + keywords="Multipath TCP, threats, security, MPTCP", + doi="10.17487/RFC6181", + } + +@misc{rfc6182, + author="A. Ford and C. Raiciu and M. Handley and S. Barre and J. Iyengar", + title="{Architectural Guidelines for Multipath TCP Development}", + howpublished="RFC 6182 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6182", + pages="1--28", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6182.txt", + key="RFC 6182", + abstract={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. 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.}, + keywords="multipath tcp architecture", + doi="10.17487/RFC6182", + } + +@misc{rfc6183, + author="A. Kobayashi and B. Claise and G. Muenz and K. Ishibashi", + title="{IP Flow Information Export (IPFIX) Mediation: Framework}", + howpublished="RFC 6183 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6183", + pages="1--29", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6183.txt", + key="RFC 6183", + abstract={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.}, + doi="10.17487/RFC6183", + } + +@misc{rfc6184, + author="Y.-K. Wang and R. Even and T. Kristensen and R. Jesup", + title="{RTP Payload Format for H.264 Video}", + howpublished="RFC 6184 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6184", + pages="1--101", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6184.txt", + key="RFC 6184", + abstract={This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, 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. 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]}, + keywords="AVC, H.264/AVC, Advanced Video Coding", + doi="10.17487/RFC6184", + } + +@misc{rfc6185, + author="T. Kristensen and P. Luthi", + title="{RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video}", + howpublished="RFC 6185 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6185", + pages="1--22", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6185.txt", + key="RFC 6185", + abstract={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]}, + keywords="H.264, H.241, ITU-T, RTP, Video, SDP, RCDO", + doi="10.17487/RFC6185", + } + +@misc{rfc6186, + author="C. Daboo", + title="{Use of SRV Records for Locating Email Submission/Access Services}", + howpublished="RFC 6186 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6186", + pages="1--9", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8314", +url="https://www.rfc-editor.org/rfc/rfc6186.txt", + key="RFC 6186", + abstract={This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]}, + keywords="imap, pop3, smtp, dns, discovery", + doi="10.17487/RFC6186", + } + +@misc{rfc6187, + author="K. Igoe and D. Stebila", + title="{X.509v3 Certificates for Secure Shell Authentication}", + howpublished="RFC 6187 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6187", + pages="1--16", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6187.txt", + key="RFC 6187", + abstract={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]}, + keywords="", + doi="10.17487/RFC6187", + } + +@misc{rfc6188, + author="D. McGrew", + title="{The Use of AES-192 and AES-256 in Secure RTP}", + howpublished="RFC 6188 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6188", + pages="1--16", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6188.txt", + key="RFC 6188", + abstract={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]}, + keywords="SRTP", + doi="10.17487/RFC6188", + } + +@misc{rfc6189, + author="P. Zimmermann and A. {Johnston (Ed.)} and J. Callas", + title="{ZRTP: Media Path Key Agreement for Unicast Secure RTP}", + howpublished="RFC 6189 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6189", + pages="1--115", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6189.txt", + key="RFC 6189", + abstract={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 med ia 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.}, + doi="10.17487/RFC6189", + } + +@misc{rfc6190, + author="S. Wenger and Y.-K. Wang and T. Schierl and A. Eleftheriadis", + title="{RTP Payload Format for Scalable Video Coding}", + howpublished="RFC 6190 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6190", + pages="1--100", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6190.txt", + key="RFC 6190", + abstract={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]}, + keywords="SVC, AVC, H.264/AVC, Advanced Video Coding, Scalable Video Coding", + doi="10.17487/RFC6190", + } + +@misc{rfc6191, + author="F. Gont", + title="{Reducing the TIME-WAIT State Using TCP Timestamps}", + howpublished="RFC 6191 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6191", + pages="1--10", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6191.txt", + key="RFC 6191", + abstract={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.}, + keywords="", + doi="10.17487/RFC6191", + } + +@misc{rfc6192, + author="D. Dugal and C. Pignataro and R. Dunn", + title="{Protecting the Router Control Plane}", + howpublished="RFC 6192 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6192", + pages="1--25", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6192.txt", + key="RFC 6192", + abstract={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. 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.}, + keywords="ACL, Router Control Plane Protection, Filter", + doi="10.17487/RFC6192", + } + +@misc{rfc6193, + author="M. Saito and D. Wing and M. Toyama", + title="{Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)}", + howpublished="RFC 6193 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6193", + pages="1--22", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6193.txt", + key="RFC 6193", + abstract={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.}, + keywords="SIP, IPsec, setup, VPN", + doi="10.17487/RFC6193", + } + +@misc{rfc6194, + author="T. Polk and L. Chen and S. Turner and P. Hoffman", + title="{Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms}", + howpublished="RFC 6194 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6194", + pages="1--7", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6194.txt", + key="RFC 6194", + abstract={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.}, + doi="10.17487/RFC6194", + } + +@misc{rfc6195, + author="D. {Eastlake 3rd}", + title="{Domain Name System (DNS) IANA Considerations}", + howpublished="RFC 6195 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6195", + pages="1--17", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6895", +url="https://www.rfc-editor.org/rfc/rfc6195.txt", + key="RFC 6195", + abstract={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.}, + keywords="RRTYPE, RCODE, AFSDB", + doi="10.17487/RFC6195", + } + +@misc{rfc6196, + author="A. Melnikov", + title="{Moving mailserver: URI Scheme to Historic}", + howpublished="RFC 6196 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6196", + pages="1--3", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6196.txt", + key="RFC 6196", + abstract={This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]}, + keywords="mailserver, URI", + doi="10.17487/RFC6196", + } + +@misc{rfc6197, + author="K. Wolf", + title="{Location-to-Service Translation (LoST) Service List Boundary Extension}", + howpublished="RFC 6197 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6197", + pages="1--15", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6197.txt", + key="RFC 6197", + abstract={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 <listServicesByLocation> 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.}, + keywords="listservicesbylocation", + doi="10.17487/RFC6197", + } + +@misc{rfc6198, + author="B. Decraene and P. Francois and C. Pelsser and Z. Ahmad and A.J. Elizondo Armengol and T. Takeda", + title="{Requirements for the Graceful Shutdown of BGP Sessions}", + howpublished="RFC 6198 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6198", + pages="1--20", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6198.txt", + key="RFC 6198", + abstract={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.}, + keywords="routing, BGP, graceful, shutdown, connectivity loss, maintenance, network operation, make-before-break, planned", + doi="10.17487/RFC6198", + } + +@misc{rfc6201, + author="R. Asati and C. Pignataro and F. Calabria and C. Olvera", + title="{Device Reset Characterization}", + howpublished="RFC 6201 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6201", + pages="1--17", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6201.txt", + key="RFC 6201", + abstract={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. 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.}, + keywords="operation redundancy failover", + doi="10.17487/RFC6201", + } + +@misc{rfc6202, + author="S. Loreto and P. Saint-Andre and S. Salsano and G. Wilkins", + title="{Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP}", + howpublished="RFC 6202 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6202", + pages="1--19", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6202.txt", + key="RFC 6202", + abstract={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.}, + keywords="Hypertext Transfer Protocol, bidirectional HTTP, HTTP long polling, HTTP streaming", + doi="10.17487/RFC6202", + } + +@misc{rfc6203, + author="T. Sirainen", + title="{IMAP4 Extension for Fuzzy Search}", + howpublished="RFC 6203 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6203", + pages="1--7", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6203.txt", + key="RFC 6203", + abstract={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]}, + keywords="email", + doi="10.17487/RFC6203", + } + +@misc{rfc6204, + author="H. Singh and W. Beebee and C. Donley and B. Stark and O. {Troan (Ed.)}", + title="{Basic Requirements for IPv6 Customer Edge Routers}", + howpublished="RFC 6204 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6204", + pages="1--17", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7084", +url="https://www.rfc-editor.org/rfc/rfc6204.txt", + key="RFC 6204", + abstract={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.}, + keywords="IPv6 CE requirements", + doi="10.17487/RFC6204", + } + +@misc{rfc6205, + author="T. {Otani (Ed.)} and D. {Li (Ed.)}", + title="{Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers}", + howpublished="RFC 6205 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6205", + pages="1--15", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7699, 8359", +url="https://www.rfc-editor.org/rfc/rfc6205.txt", + key="RFC 6205", + abstract={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. 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. 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 protocol s. [STANDARDS-TRACK]}, + keywords="DWDM, CWDM, Wavelength Label, LSC", + doi="10.17487/RFC6205", + } + +@misc{rfc6206, + author="P. Levis and T. Clausen and J. Hui and O. Gnawali and J. Ko", + title="{The Trickle Algorithm}", + howpublished="RFC 6206 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6206", + pages="1--13", + year=2011, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6206.txt", + key="RFC 6206", + abstract={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]}, + keywords="Consistency, Eventual consistency, Low-power, Low power", + doi="10.17487/RFC6206", + } + +@misc{rfc6207, + author="R. {Denenberg (Ed.)}", + title="{The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml}", + howpublished="RFC 6207 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6207", + pages="1--11", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6207.txt", + key="RFC 6207", + abstract={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.}, + keywords="mods, Metadata Object Description Schema, MADS, Metadata Authority Description Schema, METS, Metadata Encoding and Transmission Standard, MARCXML, MARC21 XML Schema, SRU, Search/Retrieve via URL Response Format", + doi="10.17487/RFC6207", + } + +@misc{rfc6208, + author="K. {Sankar (Ed.)} and A. Jones", + title="{Cloud Data Management Interface (CDMI) Media Types}", + howpublished="RFC 6208 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6208", + pages="1--13", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6208.txt", + key="RFC 6208", + abstract={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: o application/cdmi-object o application/cdmi-container o application/cdmi-domain o application/cdmi-capability o application/cdmi-queue This document is not an Internet Standards Track specification; it is published for informational purposes.}, + keywords="snia, Storage Networking Industry Association", + doi="10.17487/RFC6208", + } + +@misc{rfc6209, + author="W. Kim and J. Lee and J. Park and D. Kwon", + title="{Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)}", + howpublished="RFC 6209 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6209", + pages="1--9", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6209.txt", + key="RFC 6209", + abstract={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.}, + keywords="aria encryption", + doi="10.17487/RFC6209", + } + +@misc{rfc6210, + author="J. Schaad", + title="{Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME}", + howpublished="RFC 6210 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6210", + pages="1--14", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6210.txt", + key="RFC 6210", + abstract={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.}, + keywords="example, MD5-XOR, Parameterized", + doi="10.17487/RFC6210", + } + +@misc{rfc6211, + author="J. Schaad", + title="{Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute}", + howpublished="RFC 6211 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6211", + pages="1--11", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6211.txt", + key="RFC 6211", + abstract={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]}, + keywords="example, s/mime, SMIME", + doi="10.17487/RFC6211", + } + +@misc{rfc6212, + author="M. Kucherawy", + title="{Authentication-Results Registration for Vouch by Reference Results}", + howpublished="RFC 6212 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6212", + pages="1--7", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6212.txt", + key="RFC 6212", + abstract={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]}, + keywords="VBR, Reputation, DKIM", + doi="10.17487/RFC6212", + } + +@misc{rfc6213, + author="C. Hopps and L. Ginsberg", + title="{IS-IS BFD-Enabled TLV}", + howpublished="RFC 6213 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6213", + pages="1--7", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6213.txt", + key="RFC 6213", + abstract={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]}, + keywords="type-length-value, Bidirectional Forwarding Detection", + doi="10.17487/RFC6213", + } + +@misc{rfc6214, + author="B. Carpenter and R. Hinden", + title="{Adaptation of RFC 1149 for IPv6}", + howpublished="RFC 6214 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6214", + pages="1--7", + year=2011, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6214.txt", + key="RFC 6214", + abstract={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.}, + keywords="avian carrier, april fool", + doi="10.17487/RFC6214", + } + +@misc{rfc6215, + author="M. Bocci and L. Levrau and D. Frost", + title="{MPLS Transport Profile User-to-Network and Network-to-Network Interfaces}", + howpublished="RFC 6215 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6215", + pages="1--6", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6215.txt", + key="RFC 6215", + abstract={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. 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.}, + doi="10.17487/RFC6215", + } + +@misc{rfc6216, + author="C. Jennings and K. Ono and R. Sparks and B. {Hibbard (Ed.)}", + title="{Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms}", + howpublished="RFC 6216 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6216", + pages="1--67", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6216.txt", + key="RFC 6216", + abstract={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.}, + doi="10.17487/RFC6216", + } + +@misc{rfc6217, + author="T. Ritter", + title="{Regional Broadcast Using an Atmospheric Link Layer}", + howpublished="RFC 6217 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6217", + pages="1--9", + year=2011, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6217.txt", + key="RFC 6217", + abstract={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.}, + doi="10.17487/RFC6217", + } + +@misc{rfc6218, + author="G. Zorn and T. Zhang and J. Walker and J. Salowey", + title="{Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material}", + howpublished="RFC 6218 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6218", + pages="1--18", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6218.txt", + key="RFC 6218", + abstract={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.}, + keywords="Security", + doi="10.17487/RFC6218", + } + +@misc{rfc6219, + author="X. Li and C. Bao and M. Chen and H. Zhang and J. Wu", + title="{The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition}", + howpublished="RFC 6219 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6219", + pages="1--22", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6219.txt", + key="RFC 6219", + abstract={This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. 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 i nformational purposes.}, + keywords="Stateless IPv4/IPv6 translation, IPv4/IPv6 Header Translation, IPv4-embedded IPv6 Address, IPv4/IPv6 Multicast Translation, stateless NAT64", + doi="10.17487/RFC6219", + } + +@misc{rfc6220, + author="D. {McPherson (Ed.)} and O. {Kolkman (Ed.)} and J. {Klensin (Ed.)} and G. {Huston (Ed.)} and Internet Architecture Board", + title="{Defining the Role and Function of IETF Protocol Parameter Registry Operators}", + howpublished="RFC 6220 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6220", + pages="1--11", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6220.txt", + key="RFC 6220", + abstract={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.}, + doi="10.17487/RFC6220", + } + +@misc{rfc6221, + author="D. {Miles (Ed.)} and S. Ooghe and W. Dec and S. Krishnan and A. Kavanagh", + title="{Lightweight DHCPv6 Relay Agent}", + howpublished="RFC 6221 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6221", + pages="1--17", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6221.txt", + key="RFC 6221", + abstract={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]}, + keywords="ipv6, dsl", + doi="10.17487/RFC6221", + } + +@misc{rfc6222, + author="A. Begen and C. Perkins and D. Wing", + title="{Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)}", + howpublished="RFC 6222 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6222", + pages="1--9", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7022", +url="https://www.rfc-editor.org/rfc/rfc6222.txt", + key="RFC 6222", + abstract={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]}, + keywords="", + doi="10.17487/RFC6222", + } + +@misc{rfc6223, + author="C. Holmberg", + title="{Indication of Support for Keep-Alive}", + howpublished="RFC 6223 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6223", + pages="1--18", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6223.txt", + key="RFC 6223", + abstract={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]}, + keywords="SIP, STUN, outbound, NAT traversal", + doi="10.17487/RFC6223", + } + +@misc{rfc6224, + author="T. Schmidt and M. Waehlisch and S. Krishnan", + title="{Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains}", + howpublished="RFC 6224 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6224", + pages="1--19", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6224.txt", + key="RFC 6224", + abstract={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.}, + keywords="MLD proxy, multicast routing, mobility management, transparent handover", + doi="10.17487/RFC6224", + } + +@misc{rfc6225, + author="J. Polk and M. Linsner and M. Thomson and B. {Aboba (Ed.)}", + title="{Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information}", + howpublished="RFC 6225 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6225", + pages="1--36", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6225.txt", + key="RFC 6225", + abstract={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]}, + doi="10.17487/RFC6225", + } + +@misc{rfc6226, + author="B. Joshi and A. Kessler and D. McWalter", + title="{PIM Group-to-Rendezvous-Point Mapping}", + howpublished="RFC 6226 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6226", + pages="1--11", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6226.txt", + key="RFC 6226", + abstract={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. 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]}, + keywords="auto-RP BSR hash, algorithm", + doi="10.17487/RFC6226", + } + +@misc{rfc6227, + author="T. {Li (Ed.)}", + title="{Design Goals for Scalable Internet Routing}", + howpublished="RFC 6227 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6227", + pages="1--8", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6227.txt", + key="RFC 6227", + abstract={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.}, + keywords="routing architecture, addressing architecture", + doi="10.17487/RFC6227", + } + +@misc{rfc6228, + author="C. Holmberg", + title="{Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog}", + howpublished="RFC 6228 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6228", + pages="1--14", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6228.txt", + key="RFC 6228", + abstract={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]}, + keywords="199, Early dialog, Forking, Provisional response", + doi="10.17487/RFC6228", + } + +@misc{rfc6229, + author="J. Strombergson and S. Josefsson", + title="{Test Vectors for the Stream Cipher RC4}", + howpublished="RFC 6229 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6229", + pages="1--12", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6229.txt", + key="RFC 6229", + abstract={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.}, + keywords="arcfour128, arcfour256, arcfour, ARC4m, Stream Cipher, Test Vectors, Known Answer Test, arcfour, ARC4, WEP, WPA, RFC 4345", + doi="10.17487/RFC6229", + } + +@misc{rfc6230, + author="C. Boulton and T. Melanchuk and S. McGlashan", + title="{Media Control Channel Framework}", + howpublished="RFC 6230 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6230", + pages="1--49", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6230.txt", + key="RFC 6230", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC6230", + } + +@misc{rfc6231, + author="S. McGlashan and T. Melanchuk and C. Boulton", + title="{An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework}", + howpublished="RFC 6231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6231", + pages="1--134", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6623", +url="https://www.rfc-editor.org/rfc/rfc6231.txt", + key="RFC 6231", + abstract={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]}, + keywords="", + doi="10.17487/RFC6231", + } + +@misc{rfc6232, + author="F. Wei and Y. Qin and Z. Li and T. Li and J. Dong", + title="{Purge Originator Identification TLV for IS-IS}", + howpublished="RFC 6232 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6232", + pages="1--6", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6232.txt", + key="RFC 6232", + abstract={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. 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. This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]}, + keywords="Purge Originator Identification, IIH:n, LSP:y, SNP:n, Purge:y", + doi="10.17487/RFC6232", + } + +@misc{rfc6233, + author="T. Li and L. Ginsberg", + title="{IS-IS Registry Extension for Purges}", + howpublished="RFC 6233 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6233", + pages="1--4", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6233.txt", + key="RFC 6233", + abstract={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]}, + keywords="Intermediate System to Intermediate System, LSP, security, authentication, IANA", + doi="10.17487/RFC6233", + } + +@misc{rfc6234, + author="D. {Eastlake 3rd} and T. Hansen", + title="{US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)}", + howpublished="RFC 6234 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6234", + pages="1--127", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6234.txt", + key="RFC 6234", + abstract={Federal Information Processing Standard, FIPS}, + doi="10.17487/RFC6234", + } + +@misc{rfc6235, + author="E. Boschi and B. Trammell", + title="{IP Flow Anonymization Support}", + howpublished="RFC 6235 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6235", + pages="1--43", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6235.txt", + key="RFC 6235", + abstract={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.}, + keywords="IPFIX, flow information export, address anonymization, pseudonymization, data protection, privacy", + doi="10.17487/RFC6235", + } + +@misc{rfc6236, + author="I. Johansson and K. Jung", + title="{Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)}", + howpublished="RFC 6236 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6236", + pages="1--23", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6236.txt", + key="RFC 6236", + abstract={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]}, + keywords="", + doi="10.17487/RFC6236", + } + +@misc{rfc6237, + author="B. Leiba and A. Melnikov", + title="{IMAP4 Multimailbox SEARCH Extension}", + howpublished="RFC 6237 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6237", + pages="1--10", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7377", +url="https://www.rfc-editor.org/rfc/rfc6237.txt", + key="RFC 6237", + abstract={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.}, + keywords="email, multiple mailboxes, imapext", + doi="10.17487/RFC6237", + } + +@misc{rfc6238, + author="D. M'Raihi and S. Machani and M. Pei and J. Rydell", + title="{TOTP: Time-Based One-Time Password Algorithm}", + howpublished="RFC 6238 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6238", + pages="1--16", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6238.txt", + key="RFC 6238", + abstract={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. 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 purpo ses.}, + keywords="OTP, OATH, HOTP, two factor authentication, strong authentication", + doi="10.17487/RFC6238", + } + +@misc{rfc6239, + author="K. Igoe", + title="{Suite B Cryptographic Suites for Secure Shell (SSH)}", + howpublished="RFC 6239 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6239", + pages="1--14", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6239.txt", + key="RFC 6239", + abstract={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.}, + doi="10.17487/RFC6239", + } + +@misc{rfc6240, + author="D. {Zelig (Ed.)} and R. {Cohen (Ed.)} and T. {Nadeau (Ed.)}", + title="{Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2}", + howpublished="RFC 6240 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6240", + pages="1--67", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6240.txt", + key="RFC 6240", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). [STANDARDS-TRACK]}, + keywords="management information base, PW-CEP-STD-MIB", + doi="10.17487/RFC6240", + } + +@misc{rfc6241, + author="R. {Enns (Ed.)} and M. {Bjorklund (Ed.)} and J. {Schoenwaelder (Ed.)} and A. {Bierman (Ed.)}", + title="{Network Configuration Protocol (NETCONF)}", + howpublished="RFC 6241 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6241", + pages="1--113", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7803", +url="https://www.rfc-editor.org/rfc/rfc6241.txt", + key="RFC 6241", + abstract={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]}, + keywords="XML, Configuration, Network Management, Extensible Markup Language", + doi="10.17487/RFC6241", + } + +@misc{rfc6242, + author="M. Wasserman", + title="{Using the NETCONF Protocol over Secure Shell (SSH)}", + howpublished="RFC 6242 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6242", + pages="1--11", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6242.txt", + key="RFC 6242", + abstract={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]}, + keywords="network configuration protocol", + doi="10.17487/RFC6242", + } + +@misc{rfc6243, + author="A. Bierman and B. Lengyel", + title="{With-defaults Capability for NETCONF}", + howpublished="RFC 6243 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6243", + pages="1--26", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6243.txt", + key="RFC 6243", + abstract={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]}, + keywords="network configuration protocol", + doi="10.17487/RFC6243", + } + +@misc{rfc6244, + author="P. Shafer", + title="{An Architecture for Network Management Using NETCONF and YANG}", + howpublished="RFC 6244 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6244", + pages="1--30", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6244.txt", + key="RFC 6244", + abstract={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. 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.}, + keywords="network configuration protocol", + doi="10.17487/RFC6244", + } + +@misc{rfc6245, + author="P. Yegani and K. Leung and A. Lior and K. Chowdhury and J. Navali", + title="{Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4}", + howpublished="RFC 6245 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6245", + pages="1--8", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6245.txt", + key="RFC 6245", + abstract={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 <Care of Address, Home Address, and Home Agent Address> 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]}, + keywords="", + doi="10.17487/RFC6245", + } + +@misc{rfc6246, + author="A. {Sajassi (Ed.)} and F. Brockners and D. {Mohan (Ed.)} and Y. Serbest", + title="{Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges}", + howpublished="RFC 6246 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6246", + pages="1--20", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6246.txt", + key="RFC 6246", + abstract={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. 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.}, + keywords="ieee bridges", + doi="10.17487/RFC6246", + } + +@misc{rfc6247, + author="L. Eggert", + 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}", + howpublished="RFC 6247 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6247", + pages="1--4", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6247.txt", + key="RFC 6247", + abstract={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.}, + doi="10.17487/RFC6247", + } + +@misc{rfc6248, + author="A. Morton", + title="{RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete}", + howpublished="RFC 6248 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6248", + pages="1--6", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6248.txt", + key="RFC 6248", + abstract={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.}, + doi="10.17487/RFC6248", + } + +@misc{rfc6249, + author="A. Bryan and N. McNab and T. Tsujikawa and P. Poeml and H. Nordstrom", + title="{Metalink/HTTP: Mirrors and Hashes}", + howpublished="RFC 6249 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6249", + pages="1--21", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6249.txt", + key="RFC 6249", + abstract={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]}, + keywords="file transfer, download, link, signature, data integrity, hypertext transfer protocol, ftp, file transfer protocol, metadata, torrent", + doi="10.17487/RFC6249", + } + +@misc{rfc6250, + author="D. Thaler", + title="{Evolution of the IP Model}", + howpublished="RFC 6250 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6250", + pages="1--25", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6250.txt", + key="RFC 6250", + abstract={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.}, + keywords="Internet Protocol, IPv4, IPv6, service model", + doi="10.17487/RFC6250", + } + +@misc{rfc6251, + author="S. Josefsson", + title="{Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol}", + howpublished="RFC 6251 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6251", + pages="1--8", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6251.txt", + key="RFC 6251", + abstract={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.}, + keywords="kerberos, tls, starttls, kdc", + doi="10.17487/RFC6251", + } + +@misc{rfc6252, + author="A. {Dutta (Ed.)} and V. Fajardo and Y. Ohba and K. Taniuchi and H. Schulzrinne", + title="{A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization}", + howpublished="RFC 6252 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6252", + pages="1--57", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6252.txt", + key="RFC 6252", + abstract={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 re sults in this document. 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.}, + keywords="Mobility, Optimization, Proactive handoff, Link-layer security, Handover taxonomy, Layer 2 handoff, Layer 3 handoff, Network discovery, Handover delay, Packet loss, Proactive binding update, Multi-interface, IP address acquisition, Tunnel management", + doi="10.17487/RFC6252", + } + +@misc{rfc6253, + author="T. Heer and S. Varjonen", + title="{Host Identity Protocol Certificates}", + howpublished="RFC 6253 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6253", + pages="1--12", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8002", +url="https://www.rfc-editor.org/rfc/rfc6253.txt", + key="RFC 6253", + abstract={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. 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. This document updates RFC 5201. This document defines an Experimental Protocol for the Internet community.}, + doi="10.17487/RFC6253", + } + +@misc{rfc6254, + author="M. McFadden", + title="{Request to Move RFC 2754 to Historic Status}", + howpublished="RFC 6254 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6254", + pages="1--3", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6254.txt", + key="RFC 6254", + abstract={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.}, + keywords="RPS", + doi="10.17487/RFC6254", + } + +@misc{rfc6255, + author="M. Blanchet", + title="{Delay-Tolerant Networking Bundle Protocol IANA Registries}", + howpublished="RFC 6255 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6255", + pages="1--9", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6255.txt", + key="RFC 6255", + abstract={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.}, + keywords="DTN, SNDV, DTNRG, Space networking", + doi="10.17487/RFC6255", + } + +@misc{rfc6256, + author="W. Eddy and E. Davies", + title="{Using Self-Delimiting Numeric Values in Protocols}", + howpublished="RFC 6256 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6256", + pages="1--17", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6256.txt", + key="RFC 6256", + abstract={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.}, + keywords="SDNV, DTN", + doi="10.17487/RFC6256", + } + +@misc{rfc6257, + author="S. Symington and S. Farrell and H. Weiss and P. Lovell", + title="{Bundle Security Protocol Specification}", + howpublished="RFC 6257 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6257", + pages="1--60", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6257.txt", + key="RFC 6257", + abstract={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. 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.}, + doi="10.17487/RFC6257", + } + +@misc{rfc6258, + author="S. Symington", + title="{Delay-Tolerant Networking Metadata Extension Block}", + howpublished="RFC 6258 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6258", + pages="1--10", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6258.txt", + key="RFC 6258", + abstract={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.}, + keywords="DTN, Delay-Tolerant Networking, Distruption-Tolerant Networking", + doi="10.17487/RFC6258", + } + +@misc{rfc6259, + author="S. Symington", + title="{Delay-Tolerant Networking Previous-Hop Insertion Block}", + howpublished="RFC 6259 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6259", + pages="1--10", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6259.txt", + key="RFC 6259", + abstract={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 h as 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.}, + keywords="DTN, Delay-Tolerant Networking, Distruption-Tolerant Networking", + doi="10.17487/RFC6259", + } + +@misc{rfc6260, + author="S. Burleigh", + title="{Compressed Bundle Header Encoding (CBHE)}", + howpublished="RFC 6260 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6260", + pages="1--12", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6260.txt", + key="RFC 6260", + abstract={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. 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. 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.}, + keywords="DTN, delay-tolerant networking, BP, bundle protocol, IPN", + doi="10.17487/RFC6260", + } + +@misc{rfc6261, + author="A. Keranen", + title="{Encrypted Signaling Transport Modes for the Host Identity Protocol}", + howpublished="RFC 6261 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6261", + pages="1--13", + year=2011, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6261.txt", + key="RFC 6261", + abstract={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.}, + doi="10.17487/RFC6261", + } + +@misc{rfc6262, + author="S. Ikonin", + title="{RTP Payload Format for IP-MR Speech Codec}", + howpublished="RFC 6262 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6262", + pages="1--19", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6262.txt", + key="RFC 6262", + abstract={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]}, + keywords="ipmr, vocoder, multirate, scalable, scalability", + doi="10.17487/RFC6262", + } + +@misc{rfc6263, + author="X. Marjou and A. Sollaud", + title="{Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows}", + howpublished="RFC 6263 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6263", + pages="1--12", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6263.txt", + key="RFC 6263", + abstract={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]}, + keywords="AVT, SDP, port", + doi="10.17487/RFC6263", + } + +@misc{rfc6264, + author="S. Jiang and D. Guo and B. Carpenter", + title="{An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition}", + howpublished="RFC 6264 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6264", + pages="1--13", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6264.txt", + key="RFC 6264", + abstract={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. 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 an d 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.}, + doi="10.17487/RFC6264", + } + +@misc{rfc6265, + author="A. Barth", + title="{HTTP State Management Mechanism}", + howpublished="RFC 6265 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6265", + pages="1--37", + year=2011, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6265.txt", + key="RFC 6265", + abstract={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]}, + keywords="Cookie, Set-Cookie, Secure, HttpOnly", + doi="10.17487/RFC6265", + } + +@misc{rfc6266, + author="J. Reschke", + title="{Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)}", + howpublished="RFC 6266 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6266", + pages="1--14", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6266.txt", + key="RFC 6266", + abstract={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]}, + keywords="filename, attachment, inline", + doi="10.17487/RFC6266", + } + +@misc{rfc6267, + author="V. Cakulev and G. Sundaram", + title="{MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)}", + howpublished="RFC 6267 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6267", + pages="1--30", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6267.txt", + key="RFC 6267", + abstract={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.}, + keywords="Identity based encryption, authentication, key agreement", + doi="10.17487/RFC6267", + } + +@misc{rfc6268, + author="J. Schaad and S. Turner", + title="{Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)}", + howpublished="RFC 6268 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6268", + pages="1--33", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6268.txt", + key="RFC 6268", + abstract={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.}, + keywords="ASN.1, Certficate Extensions, HMAC", + doi="10.17487/RFC6268", + } + +@misc{rfc6269, + author="M. {Ford (Ed.)} and M. Boucadair and A. Durand and P. Levis and P. Roberts", + title="{Issues with IP Address Sharing}", + howpublished="RFC 6269 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6269", + pages="1--29", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6269.txt", + key="RFC 6269", + abstract={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. 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.}, + keywords="IPv4 address exhaustion, completion, shared, sharing issues", + doi="10.17487/RFC6269", + } + +@misc{rfc6270, + author="M. Yevstifeyev", + title="{The 'tn3270' URI Scheme}", + howpublished="RFC 6270 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6270", + pages="1--6", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6270.txt", + key="RFC 6270", + abstract={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]}, + keywords="URI, Telnet, Telnet 3270, TN3270", + doi="10.17487/RFC6270", + } + +@misc{rfc6271, + author="J-F. Mule", + title="{Requirements for SIP-Based Session Peering}", + howpublished="RFC 6271 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6271", + pages="1--23", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6271.txt", + key="RFC 6271", + abstract={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.}, + keywords="IETF speermint, guidelines, requirements for session interconnects, session peering, SIP interconnects, VoIP peering", + doi="10.17487/RFC6271", + } + +@misc{rfc6272, + author="F. Baker and D. Meyer", + title="{Internet Protocols for the Smart Grid}", + howpublished="RFC 6272 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6272", + pages="1--66", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6272.txt", + key="RFC 6272", + abstract={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.}, + doi="10.17487/RFC6272", + } + +@misc{rfc6273, + author="A. Kukec and S. Krishnan and S. Jiang", + title="{The Secure Neighbor Discovery (SEND) Hash Threat Analysis}", + howpublished="RFC 6273 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6273", + pages="1--7", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6273.txt", + key="RFC 6273", + abstract={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.}, + doi="10.17487/RFC6273", + } + +@misc{rfc6274, + author="F. Gont", + title="{Security Assessment of the Internet Protocol Version 4}", + howpublished="RFC 6274 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6274", + pages="1--75", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6274.txt", + key="RFC 6274", + abstract={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.}, + keywords="vulnerabilities, Denial of Service, resiliency, hardening, information leakage", + doi="10.17487/RFC6274", + } + +@misc{rfc6275, + author="C. {Perkins (Ed.)} and D. Johnson and J. Arkko", + title="{Mobility Support in IPv6}", + howpublished="RFC 6275 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6275", + pages="1--169", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6275.txt", + key="RFC 6275", + abstract={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]}, + keywords="MIPv6, mobility, IPv6, internet protocol, nodes", + doi="10.17487/RFC6275", + } + +@misc{rfc6276, + author="R. Droms and P. Thubert and F. Dupont and W. Haddad and C. Bernardos", + title="{DHCPv6 Prefix Delegation for Network Mobility (NEMO)}", + howpublished="RFC 6276 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6276", + pages="1--14", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6276.txt", + key="RFC 6276", + abstract={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]}, + keywords="IPv6, mobile router, home agent, mobile network prefix", + doi="10.17487/RFC6276", + } + +@misc{rfc6277, + author="S. Santesson and P. Hallam-Baker", + title="{Online Certificate Status Protocol Algorithm Agility}", + howpublished="RFC 6277 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6277", + pages="1--11", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6960", +url="https://www.rfc-editor.org/rfc/rfc6277.txt", + key="RFC 6277", + abstract={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]}, + keywords="ocsp", + doi="10.17487/RFC6277", + } + +@misc{rfc6278, + author="J. Herzog and R. Khazan", + title="{Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax}", + howpublished="RFC 6278 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6278", + pages="1--16", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6278.txt", + key="RFC 6278", + abstract={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.}, + keywords="set-key, group-key", + doi="10.17487/RFC6278", + } + +@misc{rfc6279, + author="M. {Liebsch (Ed.)} and S. Jeong and Q. Wu", + title="{Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement}", + howpublished="RFC 6279 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6279", + pages="1--14", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6279.txt", + key="RFC 6279", + abstract={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.}, + keywords="Local Routing, Route Optimization, Traffic Offload", + doi="10.17487/RFC6279", + } + +@misc{rfc6280, + author="R. Barnes and M. Lepinski and A. Cooper and J. Morris and H. Tschofenig and H. Schulzrinne", + title="{An Architecture for Location and Location Privacy in Internet Applications}", + howpublished="RFC 6280 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6280", + pages="1--41", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6280.txt", + key="RFC 6280", + abstract={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.}, + keywords="geolocation, geopriv", + doi="10.17487/RFC6280", + } + +@misc{rfc6281, + author="S. Cheshire and Z. Zhu and R. Wakikawa and L. Zhang", + title="{Understanding Apple's Back to My Mac (BTMM) Service}", + howpublished="RFC 6281 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6281", + pages="1--16", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6281.txt", + key="RFC 6281", + abstract={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.}, + doi="10.17487/RFC6281", + } + +@misc{rfc6282, + author="J. {Hui (Ed.)} and P. Thubert", + title="{Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks}", + howpublished="RFC 6282 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6282", + pages="1--24", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8066", +url="https://www.rfc-editor.org/rfc/rfc6282.txt", + key="RFC 6282", + abstract={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]}, + keywords="LLN, Low Power, radio 802.15.4, powerline, ISA100.11a, RFC 4944", + doi="10.17487/RFC6282", + } + +@misc{rfc6283, + author="A. Jerman Blazic and S. Saljic and T. Gondrom", + title="{Extensible Markup Language Evidence Record Syntax (XMLERS)}", + howpublished="RFC 6283 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6283", + pages="1--43", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6283.txt", + key="RFC 6283", + abstract={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]}, + keywords="long term, trust, integrity, long term integrity, data preservation, document preservation, time-stamp, time-stamping, archive time stamp, electronic archive, electronic archiving, trusted archiving, long-term archive, archive data, evidence, evidence record, evidence record syntax, hash tree, ERS, XML, hash, signature, renewal, algorithm, cryptography", + doi="10.17487/RFC6283", + } + +@misc{rfc6284, + author="A. Begen and D. Wing and T. Van Caenegem", + title="{Port Mapping between Unicast and Multicast RTP Sessions}", + howpublished="RFC 6284 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6284", + pages="1--30", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6284.txt", + key="RFC 6284", + abstract={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]}, + keywords="Port mapping, port translation, RTP, multicast, NAT", + doi="10.17487/RFC6284", + } + +@misc{rfc6285, + author="B. Ver Steeg and A. Begen and T. Van Caenegem and Z. Vax", + title="{Unicast-Based Rapid Acquisition of Multicast RTP Sessions}", + howpublished="RFC 6285 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6285", + pages="1--56", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6285.txt", + key="RFC 6285", + abstract={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. 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]}, + keywords="SSM, multicast, IPTV, fast channel change", + doi="10.17487/RFC6285", + } + +@misc{rfc6286, + author="E. Chen and J. Yuan", + title="{Autonomous-System-Wide Unique BGP Identifier for BGP-4}", + howpublished="RFC 6286 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6286", + pages="1--4", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6286.txt", + key="RFC 6286", + abstract={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]}, + keywords="", + doi="10.17487/RFC6286", + } + +@misc{rfc6287, + author="D. M'Raihi and J. Rydell and S. Bajaj and S. Machani and D. Naccache", + title="{OCRA: OATH Challenge-Response Algorithm}", + howpublished="RFC 6287 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6287", + pages="1--38", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6287.txt", + key="RFC 6287", + abstract={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.}, + keywords="HOTP, TOTP, One-Time Password, Authentication, Signature", + doi="10.17487/RFC6287", + } + +@misc{rfc6288, + author="C. Reed", + title="{URN Namespace for the Defence Geospatial Information Working Group (DGIWG)}", + howpublished="RFC 6288 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6288", + pages="1--8", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6288.txt", + key="RFC 6288", + abstract={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. 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.}, + keywords="Namespace Identifier, nid, DGIWG Registry System, drs", + doi="10.17487/RFC6288", + } + +@misc{rfc6289, + author="E. Cardona and S. Channabasappa and J-F. Mule", + title="{A Uniform Resource Name (URN) Namespace for CableLabs}", + howpublished="RFC 6289 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6289", + pages="1--7", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6289.txt", + key="RFC 6289", + abstract={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.}, + keywords="namespace identifier, nid", + doi="10.17487/RFC6289", + } + +@misc{rfc6290, + author="Y. {Nir (Ed.)} and D. Wierbowski and F. Detienne and P. Sethi", + title="{A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)}", + howpublished="RFC 6290 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6290", + pages="1--22", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6290.txt", + key="RFC 6290", + abstract={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. 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]}, + keywords="QCD", + doi="10.17487/RFC6290", + } + +@misc{rfc6291, + author="L. Andersson and H. van Helvoort and R. Bonica and D. Romascanu and S. Mansfield", + title="{Guidelines for the Use of the ``OAM'' Acronym in the IETF}", + howpublished="RFC 6291 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6291", + pages="1--9", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6291.txt", + key="RFC 6291", + abstract={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. 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.}, + keywords="", + doi="10.17487/RFC6291", + } + +@misc{rfc6292, + author="P. Hoffman", + title="{Requirements for a Working Group Charter Tool}", + howpublished="RFC 6292 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6292", + pages="1--11", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6433", +url="https://www.rfc-editor.org/rfc/rfc6292.txt", + key="RFC 6292", + abstract={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.}, + doi="10.17487/RFC6292", + } + +@misc{rfc6293, + author="P. Hoffman", + title="{Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker}", + howpublished="RFC 6293 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6293", + pages="1--17", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6293.txt", + key="RFC 6293", + abstract={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.}, + doi="10.17487/RFC6293", + } + +@misc{rfc6294, + author="Q. Hu and B. Carpenter", + title="{Survey of Proposed Use Cases for the IPv6 Flow Label}", + howpublished="RFC 6294 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6294", + pages="1--18", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6294.txt", + key="RFC 6294", + abstract={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.}, + keywords="Quality of service, QoS", + doi="10.17487/RFC6294", + } + +@misc{rfc6295, + author="J. Lazzaro and J. Wawrzynek", + title="{RTP Payload Format for MIDI}", + howpublished="RFC 6295 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6295", + pages="1--171", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6295.txt", + key="RFC 6295", + abstract={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]}, + keywords="asc, content streaming, DLS 2, General MIDI, MIDI, MIDI file, MIDI file streaming, MIDI light control, MIDI rendering, MIDI ringtone, MIDI streaming MIDI sequencer, MIDI time code, MIDI timecode, MIDI Manufacturers Association, MMA mpeg4generic MPEG 4, MPEG 4 Structured Audio, MPEG 4 Synthetic Coding, MTC, musical notes, network musical performance, recovery journal, Show Control, sonification, ringtone, rtpmidi, RTP, RTP MIDI, SMPTE time code, SMPTE timecode, Standard MIDI Files, XMF", + doi="10.17487/RFC6295", + } + +@misc{rfc6296, + author="M. Wasserman and F. Baker", + title="{IPv6-to-IPv6 Network Prefix Translation}", + howpublished="RFC 6296 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6296", + pages="1--32", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6296.txt", + key="RFC 6296", + abstract={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.}, + keywords="", + doi="10.17487/RFC6296", + } + +@misc{rfc6297, + author="M. Welzl and D. Ros", + title="{A Survey of Lower-than-Best-Effort Transport Protocols}", + howpublished="RFC 6297 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6297", + pages="1--18", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6297.txt", + key="RFC 6297", + abstract={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.}, + keywords="Less-than-Best-Effort, Congestion Control, LEDBAT", + doi="10.17487/RFC6297", + } + +@misc{rfc6298, + author="V. Paxson and M. Allman and J. Chu and M. Sargent", + title="{Computing TCP's Retransmission Timer}", + howpublished="RFC 6298 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6298", + pages="1--11", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6298.txt", + key="RFC 6298", + abstract={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]}, + keywords="RTO", + doi="10.17487/RFC6298", + } + +@misc{rfc6301, + author="Z. Zhu and R. Wakikawa and L. Zhang", + title="{A Survey of Mobility Support in the Internet}", + howpublished="RFC 6301 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6301", + pages="1--33", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6301.txt", + key="RFC 6301", + abstract={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.}, + doi="10.17487/RFC6301", + } + +@misc{rfc6302, + author="A. Durand and I. Gashinsky and D. Lee and S. Sheppard", + title="{Logging Recommendations for Internet-Facing Servers}", + howpublished="RFC 6302 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6302", + pages="1--5", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6302.txt", + key="RFC 6302", + abstract={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.}, + keywords="port logging", + doi="10.17487/RFC6302", + } + +@misc{rfc6303, + author="M. Andrews", + title="{Locally Served DNS Zones}", + howpublished="RFC 6303 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6303", + pages="1--10", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6303.txt", + key="RFC 6303", + abstract={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.}, + keywords="AS112, Reverse, IN-ADDR.ARPA, IP6.ARPA, RFC1918", + doi="10.17487/RFC6303", + } + +@misc{rfc6304, + author="J. Abley and W. Maton", + title="{AS112 Nameserver Operations}", + howpublished="RFC 6304 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6304", + pages="1--18", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7534", +url="https://www.rfc-editor.org/rfc/rfc6304.txt", + key="RFC 6304", + abstract={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. 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. 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. 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.}, + keywords="DNS, RFC1918", + doi="10.17487/RFC6304", + } + +@misc{rfc6305, + author="J. Abley and W. Maton", + title="{I'm Being Attacked by PRISONER.IANA.ORG!}", + howpublished="RFC 6305 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6305", + pages="1--8", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6305.txt", + key="RFC 6305", + abstract={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. 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. 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. 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 inf ormational purposes.}, + doi="10.17487/RFC6305", + } + +@misc{rfc6306, + author="P. Frejborg", + title="{Hierarchical IPv4 Framework}", + howpublished="RFC 6306 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6306", + pages="1--65", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6306.txt", + key="RFC 6306", + abstract={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. 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.}, + keywords="core address space, area locators, alocs, edge address space, endpoint locators, elocs", + doi="10.17487/RFC6306", + } + +@misc{rfc6307, + author="D. {Black (Ed.)} and L. {Dunbar (Ed.)} and M. Roth and R. Solomon", + title="{Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks}", + howpublished="RFC 6307 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6307", + pages="1--21", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6307.txt", + key="RFC 6307", + abstract={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]}, + keywords="", + doi="10.17487/RFC6307", + } + +@misc{rfc6308, + author="P. Savola", + title="{Overview of the Internet Multicast Addressing Architecture}", + howpublished="RFC 6308 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6308", + pages="1--14", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6308.txt", + key="RFC 6308", + abstract={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.}, + keywords="assignment, allocation, SSM, ASM, GLOP", + doi="10.17487/RFC6308", + } + +@misc{rfc6309, + author="J. Arkko and A. Keranen and J. Mattsson", + title="{IANA Rules for MIKEY (Multimedia Internet KEYing)}", + howpublished="RFC 6309 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6309", + pages="1--6", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6309.txt", + key="RFC 6309", + abstract={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]}, + keywords="short-term key message, long-term key message, oma, bac, browser and content, broadcast", + doi="10.17487/RFC6309", + } + +@misc{rfc6310, + author="M. Aissaoui and P. Busschbach and L. Martini and M. Morrow and T. Nadeau and Y(J). Stein", + title="{Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping}", + howpublished="RFC 6310 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6310", + pages="1--40", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6310.txt", + key="RFC 6310", + abstract={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]}, + keywords="interworking, defect state, defect indication, pseudowire, OAM", + doi="10.17487/RFC6310", + } + +@misc{rfc6311, + author="R. {Singh (Ed.)} and G. Kalyani and Y. Nir and Y. Sheffer and D. Zhang", + title="{Protocol Support for High Availability of IKEv2/IPsec}", + howpublished="RFC 6311 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6311", + pages="1--26", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6311.txt", + key="RFC 6311", + abstract={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. 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]}, + keywords="IPsec high availability, load sharing, clustering, fail-over", + doi="10.17487/RFC6311", + } + +@misc{rfc6312, + author="R. Koodli", + title="{Mobile Networks Considerations for IPv6 Deployment}", + howpublished="RFC 6312 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6312", + pages="1--17", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 6342", +url="https://www.rfc-editor.org/rfc/rfc6312.txt", + key="RFC 6312", + abstract={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.}, + doi="10.17487/RFC6312", + } + +@misc{rfc6313, + author="B. Claise and G. Dhandapani and P. Aitken and S. Yates", + title="{Export of Structured Data in IP Flow Information Export (IPFIX)}", + howpublished="RFC 6313 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6313", + pages="1--71", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6313.txt", + key="RFC 6313", + abstract={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]}, + keywords="ipfix information model", + doi="10.17487/RFC6313", + } + +@misc{rfc6314, + author="C. Boulton and J. Rosenberg and G. Camarillo and F. Audet", + title="{NAT Traversal Practices for Client-Server SIP}", + howpublished="RFC 6314 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6314", + pages="1--60", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6314.txt", + key="RFC 6314", + abstract={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.}, + doi="10.17487/RFC6314", + } + +@misc{rfc6315, + author="E. Guy and K. Darilion", + title="{IANA Registration for Enumservice 'iax'}", + howpublished="RFC 6315 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6315", + pages="1--6", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6315.txt", + key="RFC 6315", + abstract={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.}, + keywords="ENUM, E.164, VoIP, Voice over IP", + doi="10.17487/RFC6315", + } + +@misc{rfc6316, + author="M. Komu and M. Bagnulo and K. Slavov and S. {Sugimoto (Ed.)}", + title="{Sockets Application Program Interface (API) for Multihoming Shim}", + howpublished="RFC 6316 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6316", + pages="1--44", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6316.txt", + key="RFC 6316", + abstract={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. 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.}, + keywords="Shim6, HIP, identifier/locator split", + doi="10.17487/RFC6316", + } + +@misc{rfc6317, + author="M. Komu and T. Henderson", + title="{Basic Socket Interface Extensions for the Host Identity Protocol (HIP)}", + howpublished="RFC 6317 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6317", + pages="1--18", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6317.txt", + key="RFC 6317", + abstract={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.}, + keywords="host identity tag, cryptographic identity, cryptographic namespace, sockets API, Shim6, opportunistic mode, resolver, HIP wildcard address, ORCHID, source address selection, HIT prefix, locator handling", + doi="10.17487/RFC6317", + } + +@misc{rfc6318, + author="R. Housley and J. Solinas", + title="{Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)}", + howpublished="RFC 6318 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6318", + pages="1--15", + year=2011, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6318.txt", + key="RFC 6318", + abstract={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.}, + doi="10.17487/RFC6318", + } + +@misc{rfc6319, + author="M. Azinger and L. Vegoda", + title="{Issues Associated with Designating Additional Private IPv4 Address Space}", + howpublished="RFC 6319 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6319", + pages="1--12", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6319.txt", + key="RFC 6319", + abstract={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. 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.}, + keywords="private network", + doi="10.17487/RFC6319", + } + +@misc{rfc6320, + author="S. Wadhwa and J. Moisand and T. Haag and N. Voigt and T. {Taylor (Ed.)}", + title="{Protocol for Access Node Control Mechanism in Broadband Networks}", + howpublished="RFC 6320 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6320", + pages="1--82", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7256", +url="https://www.rfc-editor.org/rfc/rfc6320.txt", + key="RFC 6320", + abstract={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. 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 disti nguish it. [STANDARDS-TRACK]}, + keywords="ancp", + doi="10.17487/RFC6320", + } + +@misc{rfc6321, + author="C. Daboo and M. Douglass and S. Lees", + title="{xCal: The XML Format for iCalendar}", + howpublished="RFC 6321 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6321", + pages="1--54", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6868, 7529", +url="https://www.rfc-editor.org/rfc/rfc6321.txt", + key="RFC 6321", + abstract={This specification defines ``xCal'', an XML format for iCalendar data. [STANDARDS-TRACK]}, + keywords="extensible markup language", + doi="10.17487/RFC6321", + } + +@misc{rfc6322, + author="P. Hoffman", + title="{Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams}", + howpublished="RFC 6322 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6322", + pages="1--11", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6322.txt", + key="RFC 6322", + abstract={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.}, + doi="10.17487/RFC6322", + } + +@misc{rfc6323, + author="G. Renker and G. Fairhurst", + title="{Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)}", + howpublished="RFC 6323 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6323", + pages="1--13", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6323.txt", + key="RFC 6323", + abstract={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. 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. It is integrated into the feature set of DCCP as an end-to-end negotiable extension. [STANDARDS-TRACK]}, + keywords="DCCP, TFRC, CCID-3, CCID-4", + doi="10.17487/RFC6323", + } + +@misc{rfc6324, + author="G. Nakibly and F. Templin", + title="{Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations}", + howpublished="RFC 6324 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6324", + pages="1--19", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6324.txt", + key="RFC 6324", + abstract={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.}, + keywords="Encapsulation, ISATAP, 6rd", + doi="10.17487/RFC6324", + } + +@misc{rfc6325, + author="R. Perlman and D. {Eastlake 3rd} and D. Dutt and S. Gai and A. Ghanwani", + title="{Routing Bridges (RBridges): Base Protocol Specification}", + howpublished="RFC 6325 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6325", + pages="1--99", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6327, 6439, 7172, 7177, 7357, 7179, 7180, 7455, 7780, 7783, 8139, 8249, 8361, 8377", +url="https://www.rfc-editor.org/rfc/rfc6325.txt", + key="RFC 6325", + abstract={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. 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. 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]}, + keywords="TRILL", + doi="10.17487/RFC6325", + } + +@misc{rfc6326, + author="D. Eastlake and A. Banerjee and D. Dutt and R. Perlman and A. Ghanwani", + title="{Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS}", + howpublished="RFC 6326 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6326", + pages="1--25", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7176", +url="https://www.rfc-editor.org/rfc/rfc6326.txt", + key="RFC 6326", + abstract={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]}, + keywords="TRILL, RBridge, IS-IS, ISIS", + doi="10.17487/RFC6326", + } + +@misc{rfc6327, + author="D. {Eastlake 3rd} and R. Perlman and A. Ghanwani and D. Dutt and V. Manral", + title="{Routing Bridges (RBridges): Adjacency}", + howpublished="RFC 6327 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6327", + pages="1--26", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7177, updated by RFC 7180", +url="https://www.rfc-editor.org/rfc/rfc6327.txt", + key="RFC 6327", + abstract={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). 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]}, + keywords="RBridge, TRILL, Adjacency", + doi="10.17487/RFC6327", + } + +@misc{rfc6328, + author="D. {Eastlake 3rd}", + title="{IANA Considerations for Network Layer Protocol Identifiers}", + howpublished="RFC 6328 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6328", + pages="1--9", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6328.txt", + key="RFC 6328", + abstract={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.}, + keywords="NLPID", + doi="10.17487/RFC6328", + } + +@misc{rfc6329, + author="D. {Fedyk (Ed.)} and P. {Ashwood-Smith (Ed.)} and D. Allan and A. Bragg and P. Unbehagen", + title="{IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging}", + howpublished="RFC 6329 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6329", + pages="1--37", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6329.txt", + key="RFC 6329", + abstract={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]}, + keywords="spb", + doi="10.17487/RFC6329", + } + +@misc{rfc6330, + author="M. Luby and A. Shokrollahi and M. Watson and T. Stockhammer and L. Minder", + title="{RaptorQ Forward Error Correction Scheme for Object Delivery}", + howpublished="RFC 6330 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6330", + pages="1--69", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6330.txt", + key="RFC 6330", + abstract={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. 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. The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generat ed. [STANDARDS-TRACK]}, + keywords="FEC code, fountain code, systematic code, AL FEC code, Sub-blocking, FEC object delivery", + doi="10.17487/RFC6330", + } + +@misc{rfc6331, + author="A. Melnikov", + title="{Moving DIGEST-MD5 to Historic}", + howpublished="RFC 6331 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6331", + pages="1--6", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6331.txt", + key="RFC 6331", + abstract={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.}, + keywords="http, hypertext transfer protocol, security, simple, layer", + doi="10.17487/RFC6331", + } + +@misc{rfc6332, + author="A. Begen and E. Friedrich", + title="{Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)}", + howpublished="RFC 6332 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6332", + pages="1--16", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6332.txt", + key="RFC 6332", + abstract={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]}, + keywords="SSM, multicast, IPTV, RAMS, rapid acquisition, fast channel change", + doi="10.17487/RFC6332", + } + +@misc{rfc6333, + author="A. Durand and R. Droms and J. Woodyatt and Y. Lee", + title="{Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion}", + howpublished="RFC 6333 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6333", + pages="1--32", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7335", +url="https://www.rfc-editor.org/rfc/rfc6333.txt", + key="RFC 6333", + abstract={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]}, + keywords="NAT", + doi="10.17487/RFC6333", + } + +@misc{rfc6334, + author="D. Hankins and T. Mrugalski", + title="{Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite}", + howpublished="RFC 6334 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6334", + pages="1--7", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6334.txt", + key="RFC 6334", + abstract={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]}, + keywords="Softwire, DS-Lite", + doi="10.17487/RFC6334", + } + +@misc{rfc6335, + author="M. Cotton and L. Eggert and J. Touch and M. Westerlund and S. Cheshire", + title="{Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry}", + howpublished="RFC 6335 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6335", + pages="1--33", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6335.txt", + key="RFC 6335", + abstract={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. 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.}, + keywords="IANA, transport, ports, port numbers, allocation, assignment, procedures", + doi="10.17487/RFC6335", + } + +@misc{rfc6336, + author="M. Westerlund and C. Perkins", + title="{IANA Registry for Interactive Connectivity Establishment (ICE) Options}", + howpublished="RFC 6336 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6336", + pages="1--5", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6336.txt", + key="RFC 6336", + abstract={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]}, + keywords="", + doi="10.17487/RFC6336", + } + +@misc{rfc6337, + author="S. Okumura and T. Sawada and P. Kyzivat", + title="{Session Initiation Protocol (SIP) Usage of the Offer/Answer Model}", + howpublished="RFC 6337 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6337", + pages="1--33", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6337.txt", + key="RFC 6337", + abstract={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.}, + keywords="answer, offer, SDP, SIP", + doi="10.17487/RFC6337", + } + +@misc{rfc6338, + author="V. Giralt and R. McDuff", + title="{Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)}", + howpublished="RFC 6338 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6338", + pages="1--11", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6338.txt", + key="RFC 6338", + abstract={This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC). 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.}, + keywords="TERENA, tf-emc2", + doi="10.17487/RFC6338", + } + +@misc{rfc6339, + author="S. Josefsson and L. Hornquist Astrand", + title="{Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API)}", + howpublished="RFC 6339 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6339", + pages="1--8", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6339.txt", + key="RFC 6339", + abstract={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]}, + keywords="", + doi="10.17487/RFC6339", + } + +@misc{rfc6340, + author="R. Presuhn", + title="{Textual Conventions for the Representation of Floating-Point Numbers}", + howpublished="RFC 6340 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6340", + pages="1--7", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6340.txt", + key="RFC 6340", + abstract={This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK]}, + keywords="Network Management, IEEE 754, Floating-point, MIB, SMIv2, Textual Convention, FLOAT-TC-MIB", + doi="10.17487/RFC6340", + } + +@misc{rfc6341, + author="K. {Rehor (Ed.)} and L. {Portman (Ed.)} and A. Hutton and R. Jain", + title="{Use Cases and Requirements for SIP-Based Media Recording (SIPREC)}", + howpublished="RFC 6341 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6341", + pages="1--16", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6341.txt", + key="RFC 6341", + abstract={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. 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.}, + doi="10.17487/RFC6341", + } + +@misc{rfc6342, + author="R. Koodli", + title="{Mobile Networks Considerations for IPv6 Deployment}", + howpublished="RFC 6342 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6342", + pages="1--17", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6342.txt", + key="RFC 6342", + abstract={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.}, + doi="10.17487/RFC6342", + } + +@misc{rfc6343, + author="B. Carpenter", + title="{Advisory Guidelines for 6to4 Deployment}", + howpublished="RFC 6343 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6343", + pages="1--20", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6343.txt", + key="RFC 6343", + abstract={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.}, + keywords="IPv6 relay", + doi="10.17487/RFC6343", + } + +@misc{rfc6344, + author="G. {Bernstein (Ed.)} and D. Caviglia and R. Rabbat and H. van Helvoort", + title="{Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)}", + howpublished="RFC 6344 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6344", + pages="1--21", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6344.txt", + key="RFC 6344", + abstract={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]}, + keywords="", + doi="10.17487/RFC6344", + } + +@misc{rfc6345, + author="P. Duffy and S. Chakrabarti and R. Cragie and Y. {Ohba (Ed.)} and A. Yegin", + title="{Protocol for Carrying Authentication for Network Access (PANA) Relay Element}", + howpublished="RFC 6345 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6345", + pages="1--12", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6345.txt", + key="RFC 6345", + abstract={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]}, + keywords="EAP, ZigBee", + doi="10.17487/RFC6345", + } + +@misc{rfc6346, + author="R. {Bush (Ed.)}", + title="{The Address plus Port (A+P) Approach to the IPv4 Address Shortage}", + howpublished="RFC 6346 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6346", + pages="1--38", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6346.txt", + key="RFC 6346", + abstract={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. 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 ran ge. 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.}, + doi="10.17487/RFC6346", + } + +@misc{rfc6347, + author="E. Rescorla and N. Modadugu", + title="{Datagram Transport Layer Security Version 1.2}", + howpublished="RFC 6347 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6347", + pages="1--32", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7507, 7905", +url="https://www.rfc-editor.org/rfc/rfc6347.txt", + key="RFC 6347", + abstract={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]}, + keywords="dtls, dtls protocol", + doi="10.17487/RFC6347", + } + +@misc{rfc6348, + author="JL. Le {Roux (Ed.)} and T. {Morin (Ed.)}", + title="{Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol}", + howpublished="RFC 6348 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6348", + pages="1--20", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6348.txt", + key="RFC 6348", + abstract={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. 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.}, + keywords="MPLS, LDP, multipoint, P2MP, multicast", + doi="10.17487/RFC6348", + } + +@misc{rfc6349, + author="B. Constantine and G. Forget and R. Geib and R. Schrage", + title="{Framework for TCP Throughput Testing}", + howpublished="RFC 6349 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6349", + pages="1--27", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6349.txt", + key="RFC 6349", + abstract={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.}, + keywords="metric, TCP testing", + doi="10.17487/RFC6349", + } + +@misc{rfc6350, + author="S. Perreault", + title="{vCard Format Specification}", + howpublished="RFC 6350 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6350", + pages="1--74", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6868", +url="https://www.rfc-editor.org/rfc/rfc6350.txt", + key="RFC 6350", + abstract={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]}, + keywords="vCard", + doi="10.17487/RFC6350", + } + +@misc{rfc6351, + author="S. Perreault", + title="{xCard: vCard XML Representation}", + howpublished="RFC 6351 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6351", + pages="1--22", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6868", +url="https://www.rfc-editor.org/rfc/rfc6351.txt", + key="RFC 6351", + abstract={This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]}, + keywords="vCard", + doi="10.17487/RFC6351", + } + +@misc{rfc6352, + author="C. Daboo", + title="{CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)}", + howpublished="RFC 6352 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6352", + pages="1--48", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6764", +url="https://www.rfc-editor.org/rfc/rfc6352.txt", + key="RFC 6352", + abstract={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]}, + keywords="address, address book, contact", + doi="10.17487/RFC6352", + } + +@misc{rfc6353, + author="W. Hardaker", + title="{Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)}", + howpublished="RFC 6353 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="6353", + pages="1--65", + year=2011, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6353.txt", + key="RFC 6353", + abstract={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. 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. This document also defines a portion of the Man agement Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]}, + keywords="dtls, datagram transport layer security, tls transport model, tlstm, SNMP-TLS-TM-MIB", + doi="10.17487/RFC6353", + } + +@misc{rfc6354, + author="Q. Xie", + title="{Forward-Shifted RTP Redundancy Payload Support}", + howpublished="RFC 6354 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6354", + pages="1--13", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6354.txt", + key="RFC 6354", + abstract={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]}, + keywords="", + doi="10.17487/RFC6354", + } + +@misc{rfc6355, + author="T. Narten and J. Johnson", + title="{Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)}", + howpublished="RFC 6355 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6355", + pages="1--5", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6355.txt", + key="RFC 6355", + abstract={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]}, + keywords="universally unique identifier", + doi="10.17487/RFC6355", + } + +@misc{rfc6356, + author="C. Raiciu and M. Handley and D. Wischik", + title="{Coupled Congestion Control for Multipath Transport Protocols}", + howpublished="RFC 6356 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6356", + pages="1--12", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6356.txt", + key="RFC 6356", + abstract={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. 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 bi gger capacity. This would increase the overall efficiency of the network and also its robustness to failure. 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.}, + keywords="multipath, tcp, congestion control", + doi="10.17487/RFC6356", + } + +@misc{rfc6357, + author="V. Hilt and E. Noel and C. Shen and A. Abdelal", + title="{Design Considerations for Session Initiation Protocol (SIP) Overload Control}", + howpublished="RFC 6357 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6357", + pages="1--25", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6357.txt", + key="RFC 6357", + abstract={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.}, + keywords="Session Initiation Protocol, Overload Control, Congestion Collapse", + doi="10.17487/RFC6357", + } + +@misc{rfc6358, + author="P. Hoffman", + title="{Additional Master Secret Inputs for TLS}", + howpublished="RFC 6358 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6358", + pages="1--4", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6358.txt", + key="RFC 6358", + abstract={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.}, + keywords="tls, dtls, datagram tls", + doi="10.17487/RFC6358", + } + +@misc{rfc6359, + author="S. Ginoza and M. Cotton and A. Morris", + title="{Datatracker Extensions to Include IANA and RFC Editor Processing Information}", + howpublished="RFC 6359 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6359", + pages="1--18", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6359.txt", + key="RFC 6359", + abstract={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.}, + keywords="id-tracker, backend extensions", + doi="10.17487/RFC6359", + } + +@misc{rfc6360, + author="R. Housley", + title="{Conclusion of FYI RFC Sub-Series}", + howpublished="RFC 6360 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6360", + pages="1--3", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6360.txt", + key="RFC 6360", + abstract={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.}, + doi="10.17487/RFC6360", + } + +@misc{rfc6361, + author="J. Carlson and D. {Eastlake 3rd}", + title="{PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol}", + howpublished="RFC 6361 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6361", + pages="1--8", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6361.txt", + key="RFC 6361", + abstract={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]}, + keywords="point-to-point protocol, rbridges, routing bridges", + doi="10.17487/RFC6361", + } + +@misc{rfc6362, + author="K. {Meadors (Ed.)}", + title="{Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)}", + howpublished="RFC 6362 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6362", + pages="1--8", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6362.txt", + key="RFC 6362", + abstract={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.}, + keywords="EDIINT, AS2, Multiple, Attachments", + doi="10.17487/RFC6362", + } + +@misc{rfc6363, + author="M. Watson and A. Begen and V. Roca", + title="{Forward Error Correction (FEC) Framework}", + howpublished="RFC 6363 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6363", + pages="1--42", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6363.txt", + key="RFC 6363", + abstract={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]}, + keywords="Reliable streaming, content delivery, FEC schemes", + doi="10.17487/RFC6363", + } + +@misc{rfc6364, + author="A. Begen", + title="{Session Description Protocol Elements for the Forward Error Correction (FEC) Framework}", + howpublished="RFC 6364 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6364", + pages="1--18", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6364.txt", + key="RFC 6364", + abstract={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]}, + keywords="FEC configuration, FEC topologies", + doi="10.17487/RFC6364", + } + +@misc{rfc6365, + author="P. Hoffman and J. Klensin", + title="{Terminology Used in Internationalization in the IETF}", + howpublished="RFC 6365 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6365", + pages="1--47", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6365.txt", + key="RFC 6365", + abstract={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.}, + keywords="i18n, vocabulary, terms", + doi="10.17487/RFC6365", + } + +@misc{rfc6366, + author="J. Valin and K. Vos", + title="{Requirements for an Internet Audio Codec}", + howpublished="RFC 6366 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6366", + pages="1--17", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6366.txt", + key="RFC 6366", + abstract={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.}, + doi="10.17487/RFC6366", + } + +@misc{rfc6367, + author="S. Kanno and M. Kanda", + title="{Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)}", + howpublished="RFC 6367 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6367", + pages="1--8", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6367.txt", + key="RFC 6367", + abstract={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.}, + keywords="TLS, GCM, Eliptic Curve Encryption, Block Cipher, psk", + doi="10.17487/RFC6367", + } + +@misc{rfc6368, + author="P. Marques and R. Raszuk and K. Patel and K. Kumaki and T. Yamagata", + title="{Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)}", + howpublished="RFC 6368 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6368", + pages="1--14", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7606", +url="https://www.rfc-editor.org/rfc/rfc6368.txt", + key="RFC 6368", + abstract={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]}, + keywords="l3vpn, iBGP, loops, as-override, attribute set, attr\_set", + doi="10.17487/RFC6368", + } + +@misc{rfc6369, + author="E. Haleplidis and O. Koufopavlou and S. Denazis", + title="{Forwarding and Control Element Separation (ForCES) Implementation Experience}", + howpublished="RFC 6369 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6369", + pages="1--18", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6369.txt", + key="RFC 6369", + abstract={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.}, + doi="10.17487/RFC6369", + } + +@misc{rfc6370, + author="M. Bocci and G. Swallow and E. Gray", + title="{MPLS Transport Profile (MPLS-TP) Identifiers}", + howpublished="RFC 6370 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6370", + pages="1--17", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6370.txt", + key="RFC 6370", + abstract={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. 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]}, + doi="10.17487/RFC6370", + } + +@misc{rfc6371, + author="I. {Busi (Ed.)} and D. {Allan (Ed.)}", + title="{Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks}", + howpublished="RFC 6371 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6371", + pages="1--62", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6435", +url="https://www.rfc-editor.org/rfc/rfc6371.txt", + key="RFC 6371", + abstract={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. 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. 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. This document is not an Internet Standards Track specification; it is published for informational purpo ses.}, + doi="10.17487/RFC6371", + } + +@misc{rfc6372, + author="N. {Sprecher (Ed.)} and A. {Farrel (Ed.)}", + title="{MPLS Transport Profile (MPLS-TP) Survivability Framework}", + howpublished="RFC 6372 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6372", + pages="1--56", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6372.txt", + key="RFC 6372", + abstract={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. 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. 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 P aths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document. 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. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + keywords="Protection, Restoration, Recovery", + doi="10.17487/RFC6372", + } + +@misc{rfc6373, + author="L. {Andersson (Ed.)} and L. {Berger (Ed.)} and L. {Fang (Ed.)} and N. {Bitar (Ed.)} and E. {Gray (Ed.)}", + title="{MPLS Transport Profile (MPLS-TP) Control Plane Framework}", + howpublished="RFC 6373 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6373", + pages="1--57", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6373.txt", + key="RFC 6373", + abstract={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. 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 do cument is not an Internet Standards Track specification; it is published for informational purposes.}, + doi="10.17487/RFC6373", + } + +@misc{rfc6374, + author="D. Frost and S. Bryant", + title="{Packet Loss and Delay Measurement for MPLS Networks}", + howpublished="RFC 6374 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6374", + pages="1--52", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7214", +url="https://www.rfc-editor.org/rfc/rfc6374.txt", + key="RFC 6374", + abstract={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]}, + keywords="", + doi="10.17487/RFC6374", + } + +@misc{rfc6375, + author="D. {Frost (Ed.)} and S. {Bryant (Ed.)}", + title="{A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks}", + howpublished="RFC 6375 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6375", + pages="1--5", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6375.txt", + key="RFC 6375", + abstract={Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374. 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 describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. 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. }, + doi="10.17487/RFC6375", + } + +@misc{rfc6376, + author="D. {Crocker (Ed.)} and T. {Hansen (Ed.)} and M. {Kucherawy (Ed.)}", + title="{DomainKeys Identified Mail (DKIM) Signatures}", + howpublished="RFC 6376 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="6376", + pages="1--76", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 8301, 8463", +url="https://www.rfc-editor.org/rfc/rfc6376.txt", + key="RFC 6376", + abstract={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. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]}, + keywords="email, architecture, abuse, verification, anti-abuse, identity, integrity, responsible, author, sender, originator, email filtering, anti-phishing, mail signature", + doi="10.17487/RFC6376", + } + +@misc{rfc6377, + author="M. Kucherawy", + title="{DomainKeys Identified Mail (DKIM) and Mailing Lists}", + howpublished="RFC 6377 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6377", + pages="1--26", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6377.txt", + key="RFC 6377", + abstract={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.}, + keywords="email, architecture, verification, anti-abuse, identity, integrity, responsible, author, sender, originator", + doi="10.17487/RFC6377", + } + +@misc{rfc6378, + author="Y. {Weingarten (Ed.)} and S. Bryant and E. Osborne and N. Sprecher and A. {Fulignoli (Ed.)}", + title="{MPLS Transport Profile (MPLS-TP) Linear Protection}", + howpublished="RFC 6378 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6378", + pages="1--45", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7214, 7271, 7324", +url="https://www.rfc-editor.org/rfc/rfc6378.txt", + key="RFC 6378", + abstract={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. 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]}, + keywords="PSC, Protection State Coordination Protocol,", + doi="10.17487/RFC6378", + } + +@misc{rfc6379, + author="L. Law and J. Solinas", + title="{Suite B Cryptographic Suites for IPsec}", + howpublished="RFC 6379 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6379", + pages="1--7", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6379.txt", + key="RFC 6379", + abstract={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.}, + keywords="UI suites, user interface suites, elliptic curve, ike", + doi="10.17487/RFC6379", + } + +@misc{rfc6380, + author="K. Burgin and M. Peck", + title="{Suite B Profile for Internet Protocol Security (IPsec)}", + howpublished="RFC 6380 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6380", + pages="1--10", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6380.txt", + key="RFC 6380", + abstract={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). 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.}, + keywords="cryptographic algorithm policy, security application, suite b cryptography", + doi="10.17487/RFC6380", + } + +@misc{rfc6381, + author="R. Gellens and D. Singer and P. Frojdh", + title="{The 'Codecs' and 'Profiles' Parameters for ``Bucket'' Media Types}", + howpublished="RFC 6381 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6381", + pages="1--19", + year=2011, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6381.txt", + key="RFC 6381", + abstract={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. 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. By labeling content with the specific cod ecs 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.). 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]}, + keywords="codec, container, audio, video, 3gpp, 3gpp2", + doi="10.17487/RFC6381", + } + +@misc{rfc6382, + author="D. McPherson and R. Donnelly and F. Scalzo", + title="{Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services}", + howpublished="RFC 6382 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6382", + pages="1--10", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6382.txt", + key="RFC 6382", + abstract={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.}, + keywords="BGP, SIDR, RPKI, security, routing, operations, root, TLD, DNS, DDOS, peering, RIR, IRR, MITM", + doi="10.17487/RFC6382", + } + +@misc{rfc6383, + author="K. Shiomoto and A. Farrel", + title="{Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE}", + howpublished="RFC 6383 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6383", + pages="1--11", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6383.txt", + key="RFC 6383", + abstract={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. 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. 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.}, + keywords="RSVP-TE, GMPLS, MPLS-TE, cross-connect, data plane", + doi="10.17487/RFC6383", + } + +@misc{rfc6384, + author="I. van Beijnum", + title="{An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation}", + howpublished="RFC 6384 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6384", + pages="1--16", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6384.txt", + key="RFC 6384", + abstract={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. 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]}, + keywords="FTP, SIIT, NAT64", + doi="10.17487/RFC6384", + } + +@misc{rfc6385, + author="M. Barnes and A. Doria and H. Alvestrand and B. Carpenter", + title="{General Area Review Team (Gen-ART) Experiences}", + howpublished="RFC 6385 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6385", + pages="1--23", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6385.txt", + key="RFC 6385", + abstract={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.}, + keywords="genart", + doi="10.17487/RFC6385", + } + +@misc{rfc6386, + author="J. Bankoski and J. Koleszar and L. Quillio and J. Salonen and P. Wilkins and Y. Xu", + title="{VP8 Data Format and Decoding Guide}", + howpublished="RFC 6386 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6386", + pages="1--304", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6386.txt", + key="RFC 6386", + abstract={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.}, + doi="10.17487/RFC6386", + } + +@misc{rfc6387, + author="A. Takacs and L. Berger and D. Caviglia and D. Fedyk and J. Meuric", + title="{GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)}", + howpublished="RFC 6387 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6387", + pages="1--11", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6387.txt", + key="RFC 6387", + abstract={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]}, + keywords="rsvp, resource reservation protocol", + doi="10.17487/RFC6387", + } + +@misc{rfc6388, + author="IJ. {Wijnands (Ed.)} and I. {Minei (Ed.)} and K. Kompella and B. Thomas", + title="{Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths}", + howpublished="RFC 6388 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6388", + pages="1--39", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7358", +url="https://www.rfc-editor.org/rfc/rfc6388.txt", + key="RFC 6388", + abstract={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]}, + keywords="", + doi="10.17487/RFC6388", + } + +@misc{rfc6389, + author="R. Aggarwal and JL. Le Roux", + title="{MPLS Upstream Label Assignment for LDP}", + howpublished="RFC 6389 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6389", + pages="1--13", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6389.txt", + key="RFC 6389", + abstract={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]}, + keywords="", + doi="10.17487/RFC6389", + } + +@misc{rfc6390, + author="A. Clark and B. Claise", + title="{Guidelines for Considering New Performance Metric Development}", + howpublished="RFC 6390 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6390", + pages="1--23", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6390.txt", + key="RFC 6390", + abstract={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.}, + keywords="", + doi="10.17487/RFC6390", + } + +@misc{rfc6391, + author="S. {Bryant (Ed.)} and C. Filsfils and U. Drafz and V. Kompella and J. Regan and S. Amante", + title="{Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network}", + howpublished="RFC 6391 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6391", + pages="1--19", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7274", +url="https://www.rfc-editor.org/rfc/rfc6391.txt", + key="RFC 6391", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC6391", + } + +@misc{rfc6392, + author="R. {Alimi (Ed.)} and A. {Rahman (Ed.)} and Y. {Yang (Ed.)}", + title="{A Survey of In-Network Storage Systems}", + howpublished="RFC 6392 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6392", + pages="1--44", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6392.txt", + key="RFC 6392", + abstract={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.}, + keywords="P2P, DECADE, DECoupled Application Data Enroute", + doi="10.17487/RFC6392", + } + +@misc{rfc6393, + author="M. Yevstifeyev", + title="{Moving RFC 4693 to Historic}", + howpublished="RFC 6393 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6393", + pages="1--3", + year=2011, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6393.txt", + key="RFC 6393", + abstract={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.}, + keywords="ION, historic", + doi="10.17487/RFC6393", + } + +@misc{rfc6394, + author="R. Barnes", + title="{Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)}", + howpublished="RFC 6394 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6394", + pages="1--12", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6394.txt", + key="RFC 6394", + abstract={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]}, + keywords="TLS, PKIX", + doi="10.17487/RFC6394", + } + +@misc{rfc6395, + author="S. Gulrajani and S. Venaas", + title="{An Interface Identifier (ID) Hello Option for PIM}", + howpublished="RFC 6395 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6395", + pages="1--6", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6395.txt", + key="RFC 6395", + abstract={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]}, + keywords="", + doi="10.17487/RFC6395", + } + +@misc{rfc6396, + author="L. Blunk and M. Karir and C. Labovitz", + title="{Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format}", + howpublished="RFC 6396 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6396", + pages="1--33", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6396.txt", + key="RFC 6396", + abstract={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]}, + keywords="", + doi="10.17487/RFC6396", + } + +@misc{rfc6397, + author="T. Manderson", + title="{Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions}", + howpublished="RFC 6397 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6397", + pages="1--8", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6397.txt", + key="RFC 6397", + abstract={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]}, + keywords="GPS Coordinates, Terrestrial Coordinates, BGP Speaker, BGP Peer, BGP Latitude, BGP Longitude", + doi="10.17487/RFC6397", + } + +@misc{rfc6398, + author="F. Le {Faucheur (Ed.)}", + title="{IP Router Alert Considerations and Usage}", + howpublished="RFC 6398 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6398", + pages="1--19", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6398.txt", + key="RFC 6398", + abstract={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 doc uments an Internet Best Current Practice.}, + keywords="", + doi="10.17487/RFC6398", + } + +@misc{rfc6401, + author="F. Le Faucheur and J. Polk and K. Carlberg", + title="{RSVP Extensions for Admission Priority}", + howpublished="RFC 6401 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6401", + pages="1--32", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6401.txt", + key="RFC 6401", + abstract={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. Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC6401", + } + +@misc{rfc6402, + author="J. Schaad", + title="{Certificate Management over CMS (CMC) Updates}", + howpublished="RFC 6402 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6402", + pages="1--37", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6402.txt", + key="RFC 6402", + abstract={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. 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]}, + keywords="cyrptographic message syntax", + doi="10.17487/RFC6402", + } + +@misc{rfc6403, + author="L. Zieglar and S. Turner and M. Peck", + title="{Suite B Profile of Certificate Management over CMS}", + howpublished="RFC 6403 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6403", + pages="1--16", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6403.txt", + key="RFC 6403", + abstract={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.}, + keywords="cmc, suite b x.509 public key certificates", + doi="10.17487/RFC6403", + } + +@misc{rfc6404, + author="J. Seedorf and S. Niccolini and E. Chen and H. Scholz", + title="{Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures}", + howpublished="RFC 6404 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6404", + pages="1--22", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6404.txt", + key="RFC 6404", + abstract={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 t he 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.}, + keywords="VoIP, Security, Threats, multimedia, Threat countermeasures, SIP Interconnect, VoIP peering, Fraud prevention, Network protection, SIP, RTP, RTCP, control plane, user plane", + doi="10.17487/RFC6404", + } + +@misc{rfc6405, + author="A. {Uzelac (Ed.)} and Y. {Lee (Ed.)}", + title="{Voice over IP (VoIP) SIP Peering Use Cases}", + howpublished="RFC 6405 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6405", + pages="1--23", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6405.txt", + key="RFC 6405", + abstract={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.}, + keywords="VoIP, SIP Peering", + doi="10.17487/RFC6405", + } + +@misc{rfc6406, + author="D. {Malas (Ed.)} and J. {Livingood (Ed.)}", + title="{Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture}", + howpublished="RFC 6406 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6406", + pages="1--16", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6406.txt", + key="RFC 6406", + abstract={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.}, + doi="10.17487/RFC6406", + } + +@misc{rfc6407, + author="B. Weis and S. Rowles and T. Hardjono", + title="{The Group Domain of Interpretation}", + howpublished="RFC 6407 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6407", + pages="1--64", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6407.txt", + key="RFC 6407", + abstract={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]}, + keywords="", + doi="10.17487/RFC6407", + } + +@misc{rfc6408, + author="M. Jones and J. Korhonen and L. Morand", + title="{Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage}", + howpublished="RFC 6408 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6408", + pages="1--14", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6408.txt", + key="RFC 6408", + abstract={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]}, + keywords="Services Field, Peer Discovery", + doi="10.17487/RFC6408", + } + +@misc{rfc6409, + author="R. Gellens and J. Klensin", + title="{Message Submission for Mail}", + howpublished="RFC 6409 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="6409", + pages="1--20", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8314", +url="https://www.rfc-editor.org/rfc/rfc6409.txt", + key="RFC 6409", + abstract={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. Message relay is unaffected, and continues to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]}, + keywords="Text, Internationalization, ASCII, Unicode, UTF-8", + doi="10.17487/RFC6409", + } + +@misc{rfc6410, + author="R. Housley and D. Crocker and E. Burger", + title="{Reducing the Standards Track to Two Maturity Levels}", + howpublished="RFC 6410 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6410", + pages="1--6", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6410.txt", + key="RFC 6410", + abstract={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.}, + keywords="", + doi="10.17487/RFC6410", + } + +@misc{rfc6411, + author="M. Behringer and F. Le Faucheur and B. Weis", + title="{Applicability of Keying Methods for RSVP Security}", + howpublished="RFC 6411 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6411", + pages="1--19", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6411.txt", + key="RFC 6411", + abstract={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.}, + keywords="RSVP authentication, RSVP integrity, Resource reservation protocol, GDOI, Group domain of interpretation", + doi="10.17487/RFC6411", + } + +@misc{rfc6412, + author="S. Poretsky and B. Imhoff and K. Michielsen", + title="{Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence}", + howpublished="RFC 6412 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6412", + pages="1--29", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6412.txt", + key="RFC 6412", + abstract={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.}, + doi="10.17487/RFC6412", + } + +@misc{rfc6413, + author="S. Poretsky and B. Imhoff and K. Michielsen", + title="{Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence}", + howpublished="RFC 6413 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6413", + pages="1--42", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6413.txt", + key="RFC 6413", + abstract={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.}, + keywords="Interior Gateway Protocol", + doi="10.17487/RFC6413", + } + +@misc{rfc6414, + author="S. Poretsky and R. Papneja and J. Karthik and S. Vapiwala", + title="{Benchmarking Terminology for Protection Performance}", + howpublished="RFC 6414 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6414", + pages="1--33", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6414.txt", + key="RFC 6414", + abstract={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.}, + doi="10.17487/RFC6414", + } + +@misc{rfc6415, + author="E. {Hammer-Lahav (Ed.)} and B. Cook", + title="{Web Host Metadata}", + howpublished="RFC 6415 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6415", + pages="1--16", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6415.txt", + key="RFC 6415", + abstract={This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC6415", + } + +@misc{rfc6416, + author="M. Schmidt and F. de Bont and S. Doehla and J. Kim", + title="{RTP Payload Format for MPEG-4 Audio/Visual Streams}", + howpublished="RFC 6416 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6416", + pages="1--35", + year=2011, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6416.txt", + key="RFC 6416", + abstract={This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. 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. 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 syste m 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]}, + keywords="RFC3016, RTP, MPEG-4, Audio, Visual, Video, AAC, HE AAC, HE AAC v2, MPEG Surround", + doi="10.17487/RFC6416", + } + +@misc{rfc6417, + author="P. Eardley and L. Eggert and M. Bagnulo and R. Winter", + title="{How to Contribute Research Results to Internet Standardization}", + howpublished="RFC 6417 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6417", + pages="1--14", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6417.txt", + key="RFC 6417", + abstract={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. 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 differenc es 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.}, + doi="10.17487/RFC6417", + } + +@misc{rfc6418, + author="M. Blanchet and P. Seite", + title="{Multiple Interfaces and Provisioning Domains Problem Statement}", + howpublished="RFC 6418 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6418", + pages="1--22", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6418.txt", + key="RFC 6418", + abstract={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.}, + keywords="multi-homing, MIF, DNS, DHCP", + doi="10.17487/RFC6418", + } + +@misc{rfc6419, + author="M. Wasserman and P. Seite", + title="{Current Practices for Multiple-Interface Hosts}", + howpublished="RFC 6419 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6419", + pages="1--21", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6419.txt", + key="RFC 6419", + abstract={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.}, + keywords="current practices, multi-homing, MIF", + doi="10.17487/RFC6419", + } + +@misc{rfc6420, + author="Y. Cai and H. Ou", + title="{PIM Multi-Topology ID (MT-ID) Join Attribute}", + howpublished="RFC 6420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6420", + pages="1--13", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6420.txt", + key="RFC 6420", + abstract={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]}, + keywords="", + doi="10.17487/RFC6420", + } + +@misc{rfc6421, + author="D. {Nelson (Ed.)}", + title="{Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)}", + howpublished="RFC 6421 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6421", + pages="1--12", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6421.txt", + key="RFC 6421", + abstract={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.}, + doi="10.17487/RFC6421", + } + +@misc{rfc6422, + author="T. Lemon and Q. Wu", + title="{Relay-Supplied DHCP Options}", + howpublished="RFC 6422 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6422", + pages="1--8", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6422.txt", + key="RFC 6422", + abstract={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. 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]}, + keywords="DHCPv6 Relay, DHCPv6 option", + doi="10.17487/RFC6422", + } + +@misc{rfc6423, + author="H. Li and L. Martini and J. He and F. Huang", + title="{Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)}", + howpublished="RFC 6423 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6423", + pages="1--5", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6423.txt", + key="RFC 6423", + abstract={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]}, + keywords="", + doi="10.17487/RFC6423", + } + +@misc{rfc6424, + author="N. Bahadur and K. Kompella and G. Swallow", + title="{Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels}", + howpublished="RFC 6424 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6424", + pages="1--23", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8029, updated by RFC 7537", +url="https://www.rfc-editor.org/rfc/rfc6424.txt", + key="RFC 6424", + abstract={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]}, + keywords="MPLS OAM, lsp ping, LSP-Ping", + doi="10.17487/RFC6424", + } + +@misc{rfc6425, + author="S. {Saxena (Ed.)} and G. Swallow and Z. Ali and A. Farrel and S. Yasukawa and T. Nadeau", + title="{Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping}", + howpublished="RFC 6425 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6425", + pages="1--28", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6425.txt", + key="RFC 6425", + abstract={Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. 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''. 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. This document updates RFC 4379. [STANDARDS-TRACK]}, + keywords="p2mp", + doi="10.17487/RFC6425", + } + +@misc{rfc6426, + author="E. Gray and N. Bahadur and S. Boutros and R. Aggarwal", + title="{MPLS On-Demand Connectivity Verification and Route Tracing}", + howpublished="RFC 6426 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6426", + pages="1--22", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6426.txt", + key="RFC 6426", + abstract={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]}, + keywords="lsp ping, mpls tp, mpls-tp", + doi="10.17487/RFC6426", + } + +@misc{rfc6427, + author="G. {Swallow (Ed.)} and A. {Fulignoli (Ed.)} and M. {Vigoureux (Ed.)} and S. Boutros and D. Ward", + title="{MPLS Fault Management Operations, Administration, and Maintenance (OAM)}", + howpublished="RFC 6427 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6427", + pages="1--17", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7214", +url="https://www.rfc-editor.org/rfc/rfc6427.txt", + key="RFC 6427", + abstract={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]}, + keywords="mpls-oam", + doi="10.17487/RFC6427", + } + +@misc{rfc6428, + author="D. {Allan (Ed.)} and G. {Swallow (Ed.)} and J. {Drake (Ed.)}", + title="{Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile}", + howpublished="RFC 6428 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6428", + pages="1--21", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7214", +url="https://www.rfc-editor.org/rfc/rfc6428.txt", + key="RFC 6428", + abstract={Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). 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. 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]}, + keywords="mpls-tp, oam, Operations, Administration, and Maintenance, bfd, bidirectional forwarding dectection", + doi="10.17487/RFC6428", + } + +@misc{rfc6429, + author="M. Bashyam and M. Jethanandani and A. Ramaiah", + title="{TCP Sender Clarification for Persist Condition}", + howpublished="RFC 6429 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6429", + pages="1--7", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6429.txt", + key="RFC 6429", + abstract={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.}, + keywords="zero window probe, denial of service (DoS), security vulnerability", + doi="10.17487/RFC6429", + } + +@misc{rfc6430, + author="K. Li and B. Leiba", + title="{Email Feedback Report Type Value: not-spam}", + howpublished="RFC 6430 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6430", + pages="1--7", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6430.txt", + key="RFC 6430", + abstract={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]}, + keywords="arf, abuse reporting format", + doi="10.17487/RFC6430", + } + +@misc{rfc6431, + author="M. Boucadair and P. Levis and G. Bajko and T. Savolainen and T. Tsou", + title="{Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)}", + howpublished="RFC 6431 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6431", + pages="1--16", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6431.txt", + key="RFC 6431", + abstract={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.}, + keywords="IPv4 Address Exhaustion, IPv4 service continuity, IPv6, A+P", + doi="10.17487/RFC6431", + } + +@misc{rfc6432, + author="R. Jesske and L. Liess", + title="{Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses}", + howpublished="RFC 6432 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6432", + pages="1--4", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6432.txt", + key="RFC 6432", + abstract={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]}, + keywords="cause code", + doi="10.17487/RFC6432", + } + +@misc{rfc6433, + author="P. Hoffman", + title="{Requirements for a Working Group Milestones Tool}", + howpublished="RFC 6433 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6433", + pages="1--7", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6433.txt", + key="RFC 6433", + abstract={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.}, + keywords="working group charter, charter", + doi="10.17487/RFC6433", + } + +@misc{rfc6434, + author="E. Jankiewicz and J. Loughney and T. Narten", + title="{IPv6 Node Requirements}", + howpublished="RFC 6434 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6434", + pages="1--30", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6434.txt", + key="RFC 6434", + abstract={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.}, + keywords="Internet Protocol Version 6, Internet Protocol, IP", + doi="10.17487/RFC6434", + } + +@misc{rfc6435, + author="S. {Boutros (Ed.)} and S. {Sivabalan (Ed.)} and R. {Aggarwal (Ed.)} and M. {Vigoureux (Ed.)} and X. {Dai (Ed.)}", + title="{MPLS Transport Profile Lock Instruct and Loopback Functions}", + howpublished="RFC 6435 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6435", + pages="1--12", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6435.txt", + key="RFC 6435", + abstract={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. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK]}, + keywords="oam, operations, administration, and maintenance", + doi="10.17487/RFC6435", + } + +@misc{rfc6436, + author="S. Amante and B. Carpenter and S. Jiang", + title="{Rationale for Update to the IPv6 Flow Label Specification}", + howpublished="RFC 6436 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6436", + pages="1--13", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6436.txt", + key="RFC 6436", + abstract={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.}, + keywords="ECMP, LAG", + doi="10.17487/RFC6436", + } + +@misc{rfc6437, + author="S. Amante and B. Carpenter and S. Jiang and J. Rajahalme", + title="{IPv6 Flow Label Specification}", + howpublished="RFC 6437 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6437", + pages="1--15", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6437.txt", + key="RFC 6437", + abstract={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. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC6437", + } + +@misc{rfc6438, + author="B. Carpenter and S. Amante", + title="{Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels}", + howpublished="RFC 6438 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6438", + pages="1--9", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6438.txt", + key="RFC 6438", + abstract={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]}, + keywords="ECMP, LAG", + doi="10.17487/RFC6438", + } + +@misc{rfc6439, + author="R. Perlman and D. Eastlake and Y. Li and A. Banerjee and F. Hu", + title="{Routing Bridges (RBridges): Appointed Forwarders}", + howpublished="RFC 6439 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6439", + pages="1--15", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8139, updated by RFC 7180", +url="https://www.rfc-editor.org/rfc/rfc6439.txt", + key="RFC 6439", + abstract={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). 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 imp rove the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]}, + keywords="trill, TRansparent Interconnection of Lots of Links", + doi="10.17487/RFC6439", + } + +@misc{rfc6440, + author="G. Zorn and Q. Wu and Y. Wang", + title="{The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option}", + howpublished="RFC 6440 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6440", + pages="1--6", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6440.txt", + key="RFC 6440", + abstract={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. 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]}, + keywords="re-authentication, handover, LDN, Discovery", + doi="10.17487/RFC6440", + } + +@misc{rfc6441, + author="L. Vegoda", + title="{Time to Remove Filters for Previously Unallocated IPv4 /8s}", + howpublished="RFC 6441 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6441", + pages="1--5", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6441.txt", + key="RFC 6441", + abstract={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. 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.}, + keywords="bogons, IPv4, martians, filters", + doi="10.17487/RFC6441", + } + +@misc{rfc6442, + author="J. Polk and B. Rosen and J. Peterson", + title="{Location Conveyance for the Session Initiation Protocol}", + howpublished="RFC 6442 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6442", + pages="1--35", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8262", +url="https://www.rfc-editor.org/rfc/rfc6442.txt", + key="RFC 6442", + abstract={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]}, + keywords="sip, geographic location, location target", + doi="10.17487/RFC6442", + } + +@misc{rfc6443, + author="B. Rosen and H. Schulzrinne and J. Polk and A. Newton", + title="{Framework for Emergency Calling Using Internet Multimedia}", + howpublished="RFC 6443 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6443", + pages="1--38", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7852", +url="https://www.rfc-editor.org/rfc/rfc6443.txt", + key="RFC 6443", + abstract={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.}, + doi="10.17487/RFC6443", + } + +@misc{rfc6444, + author="H. Schulzrinne and L. Liess and H. Tschofenig and B. Stark and A. Kuett", + title="{Location Hiding: Problem Statement and Requirements}", + howpublished="RFC 6444 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6444", + pages="1--9", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6444.txt", + key="RFC 6444", + abstract={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. 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.}, + keywords="emergency call, privacy, PSAP, Location by Reference", + doi="10.17487/RFC6444", + } + +@misc{rfc6445, + author="T. {Nadeau (Ed.)} and A. {Koushik (Ed.)} and R. {Cetin (Ed.)}", + title="{Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute}", + howpublished="RFC 6445 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6445", + pages="1--53", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6445.txt", + key="RFC 6445", + abstract={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]}, + keywords="mib, frr, MPLS-FRR-GENERAL-STD-MIB, MPLS-FRR-ONE2ONE-STD-MIB, MPLS-FRR-FACILITY-STD-MIB", + doi="10.17487/RFC6445", + } + +@misc{rfc6446, + author="A. Niemi and K. Kiss and S. Loreto", + title="{Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control}", + howpublished="RFC 6446 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6446", + pages="1--25", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6446.txt", + key="RFC 6446", + abstract={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]}, + keywords="SIP, events, rate control", + doi="10.17487/RFC6446", + } + +@misc{rfc6447, + author="R. Mahy and B. Rosen and H. Tschofenig", + title="{Filtering Location Notifications in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6447 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6447", + pages="1--19", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6447.txt", + key="RFC 6447", + abstract={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]}, + keywords="geopriv, location", + doi="10.17487/RFC6447", + } + +@misc{rfc6448, + author="R. Yount", + title="{The Unencrypted Form of Kerberos 5 KRB-CRED Message}", + howpublished="RFC 6448 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6448", + pages="1--4", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6448.txt", + key="RFC 6448", + abstract={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]}, + keywords="credential", + doi="10.17487/RFC6448", + } + +@misc{rfc6449, + author="J. {Falk (Ed.)}", + title="{Complaint Feedback Loop Operational Recommendations}", + howpublished="RFC 6449 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6449", + pages="1--31", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6449.txt", + key="RFC 6449", + abstract={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. 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.}, + keywords="MAAWG, ARF, MARF, feedback loop, spam reporting", + doi="10.17487/RFC6449", + } + +@misc{rfc6450, + author="S. Venaas", + title="{Multicast Ping Protocol}", + howpublished="RFC 6450 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6450", + pages="1--24", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6450.txt", + key="RFC 6450", + abstract={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]}, + keywords="ssm, asm, ssmping, asmping", + doi="10.17487/RFC6450", + } + +@misc{rfc6451, + author="A. Forte and H. Schulzrinne", + title="{Location-to-Service Translation (LoST) Protocol Extensions}", + howpublished="RFC 6451 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6451", + pages="1--23", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6451.txt", + key="RFC 6451", + abstract={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.}, + keywords="location-based services, location, GPS, point of interest", + doi="10.17487/RFC6451", + } + +@misc{rfc6452, + author="P. {Faltstrom (Ed.)} and P. {Hoffman (Ed.)}", + title="{The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0}", + howpublished="RFC 6452 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6452", + pages="1--4", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6452.txt", + key="RFC 6452", + abstract={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]}, + keywords="DNS, IDN", + doi="10.17487/RFC6452", + } + +@misc{rfc6453, + author="F. Dijkstra and R. Hughes-Jones", + title="{A URN Namespace for the Open Grid Forum (OGF)}", + howpublished="RFC 6453 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6453", + pages="1--9", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6453.txt", + key="RFC 6453", + abstract={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.}, + keywords="identifier", + doi="10.17487/RFC6453", + } + +@misc{rfc6454, + author="A. Barth", + title="{The Web Origin Concept}", + howpublished="RFC 6454 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6454", + pages="1--20", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6454.txt", + key="RFC 6454", + abstract={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]}, + keywords="same-origin, policy, security, cross-origin", + doi="10.17487/RFC6454", + } + +@misc{rfc6455, + author="I. Fette and A. Melnikov", + title="{The WebSocket Protocol}", + howpublished="RFC 6455 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6455", + pages="1--71", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7936, 8307, 8441", +url="https://www.rfc-editor.org/rfc/rfc6455.txt", + key="RFC 6455", + abstract={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 <iframe>s and long polling). [STANDARDS-TRACK]}, + keywords="HyBi Working Group, HYBI, websocket", + doi="10.17487/RFC6455", + } + +@misc{rfc6456, + author="H. Li and R. Zheng and A. Farrel", + title="{Multi-Segment Pseudowires in Passive Optical Networks}", + howpublished="RFC 6456 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6456", + pages="1--12", + year=2011, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6456.txt", + key="RFC 6456", + abstract={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). 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. 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 Gigabi t-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. 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.}, + keywords="MPLS, PSN, PON, G-PON, XG-PON, OMCI", + doi="10.17487/RFC6456", + } + +@misc{rfc6457, + author="T. {Takeda (Ed.)} and A. Farrel", + title="{PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering}", + howpublished="RFC 6457 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6457", + pages="1--12", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6457.txt", + key="RFC 6457", + abstract={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). 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. 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''. This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer t raffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + keywords="PCEP, inter-layer, traffic engineering, MPLS, GMPLS, VNT", + doi="10.17487/RFC6457", + } + +@misc{rfc6458, + author="R. Stewart and M. Tuexen and K. Poon and P. Lei and V. Yasevich", + title="{Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)}", + howpublished="RFC 6458 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6458", + pages="1--115", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6458.txt", + key="RFC 6458", + abstract={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.}, + doi="10.17487/RFC6458", + } + +@misc{rfc6459, + author="J. {Korhonen (Ed.)} and J. Soininen and B. Patil and T. Savolainen and G. Bajko and K. Iisakkila", + title="{IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)}", + howpublished="RFC 6459 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6459", + pages="1--36", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6459.txt", + key="RFC 6459", + abstract={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.}, + keywords="Transition, Migration", + doi="10.17487/RFC6459", + } + +@misc{rfc6460, + author="M. Salter and R. Housley", + title="{Suite B Profile for Transport Layer Security (TLS)}", + howpublished="RFC 6460 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6460", + pages="1--14", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6460.txt", + key="RFC 6460", + abstract={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.}, + keywords="cryptographic algorithm policy", + doi="10.17487/RFC6460", + } + +@misc{rfc6461, + author="S. {Channabasappa (Ed.)}", + title="{Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements}", + howpublished="RFC 6461 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6461", + pages="1--15", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6461.txt", + key="RFC 6461", + abstract={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.}, + keywords="registry, registry provisioning, registrar, destination group, route group", + doi="10.17487/RFC6461", + } + +@misc{rfc6462, + author="A. Cooper", + title="{Report from the Internet Privacy Workshop}", + howpublished="RFC 6462 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6462", + pages="1--23", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6462.txt", + key="RFC 6462", + abstract={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. 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.}, + doi="10.17487/RFC6462", + } + +@misc{rfc6463, + author="J. {Korhonen (Ed.)} and S. Gundavelli and H. Yokota and X. Cui", + title="{Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6}", + howpublished="RFC 6463 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6463", + pages="1--22", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6463.txt", + key="RFC 6463", + abstract={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]}, + keywords="", + doi="10.17487/RFC6463", + } + +@misc{rfc6464, + author="J. {Lennox (Ed.)} and E. Ivov and E. Marocco", + title="{A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication}", + howpublished="RFC 6464 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6464", + pages="1--9", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6464.txt", + key="RFC 6464", + abstract={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]}, + keywords="ssrc-audio-level, ssrc, speech, sound, energy, conference, bridge", + doi="10.17487/RFC6464", + } + +@misc{rfc6465, + author="E. {Ivov (Ed.)} and E. {Marocco (Ed.)} and J. Lennox", + title="{A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication}", + howpublished="RFC 6465 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6465", + pages="1--15", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6465.txt", + key="RFC 6465", + abstract={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]}, + keywords="csrc-audio-level, csrc, speech, sound, energy, conference, bridge", + doi="10.17487/RFC6465", + } + +@misc{rfc6466, + author="G. Salgueiro", + title="{IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)}", + howpublished="RFC 6466 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6466", + pages="1--6", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6466.txt", + key="RFC 6466", + abstract={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]}, + keywords="t.38 media", + doi="10.17487/RFC6466", + } + +@misc{rfc6467, + author="T. Kivinen", + title="{Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)}", + howpublished="RFC 6467 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6467", + pages="1--10", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6467.txt", + key="RFC 6467", + abstract={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.}, + keywords="IPsec, IKE, mutual authentication, credentials, VPN gateway", + doi="10.17487/RFC6467", + } + +@misc{rfc6468, + author="A. Melnikov and B. Leiba and K. Li", + title="{Sieve Notification Mechanism: SIP MESSAGE}", + howpublished="RFC 6468 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6468", + pages="1--10", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6468.txt", + key="RFC 6468", + abstract={This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. [STANDARDS-TRACK]}, + keywords="Sieve, SIP, notification", + doi="10.17487/RFC6468", + } + +@misc{rfc6469, + author="K. Kobayashi and K. Mishima and S. Casner and C. Bormann", + title="{RTP Payload Format for DV (IEC 61834) Video}", + howpublished="RFC 6469 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6469", + pages="1--18", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6469.txt", + key="RFC 6469", + abstract={This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as ``DV'' into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. [STANDARDS-TRACK]}, + keywords="DV/RTP, real-time transport protocol", + doi="10.17487/RFC6469", + } + +@misc{rfc6470, + author="A. Bierman", + title="{Network Configuration Protocol (NETCONF) Base Notifications}", + howpublished="RFC 6470 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6470", + pages="1--15", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6470.txt", + key="RFC 6470", + abstract={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]}, + keywords="XML", + doi="10.17487/RFC6470", + } + +@misc{rfc6471, + author="C. Lewis and M. Sergeant", + title="{Overview of Best Email DNS-Based List (DNSBL) Operational Practices}", + howpublished="RFC 6471 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6471", + pages="1--21", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6471.txt", + key="RFC 6471", + abstract={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.}, + keywords="DNSBL policy", + doi="10.17487/RFC6471", + } + +@misc{rfc6472, + author="W. Kumari and K. Sriram", + title="{Recommendation for Not Using AS\_SET and AS\_CONFED\_SET in BGP}", + howpublished="RFC 6472 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6472", + pages="1--5", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6472.txt", + key="RFC 6472", + abstract={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.}, + keywords="BGPv4, Operator, RPKI, Aggregation, Route Origin", + doi="10.17487/RFC6472", + } + +@misc{rfc6473, + author="P. Saint-Andre", + title="{vCard KIND:application}", + howpublished="RFC 6473 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6473", + pages="1--5", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6473.txt", + key="RFC 6473", + abstract={This document defines a value of ``application'' for the vCard KIND property so that vCards can be used to represent software applications. [STANDARDS-TRACK]}, + keywords="vCard", + doi="10.17487/RFC6473", + } + +@misc{rfc6474, + author="K. Li and B. Leiba", + title="{vCard Format Extensions: Place of Birth, Place and Date of Death}", + howpublished="RFC 6474 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6474", + pages="1--6", + year=2011, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6474.txt", + key="RFC 6474", + abstract={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]}, + keywords="contacts, address-book, personal-information", + doi="10.17487/RFC6474", + } + +@misc{rfc6475, + author="G. Keeni and K. Koide and S. Gundavelli and R. Wakikawa", + title="{Proxy Mobile IPv6 Management Information Base}", + howpublished="RFC 6475 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6475", + pages="1--63", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6475.txt", + key="RFC 6475", + abstract={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]}, + keywords="", + doi="10.17487/RFC6475", + } + +@misc{rfc6476, + author="P. Gutmann", + title="{Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 6476 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6476", + pages="1--15", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6476.txt", + key="RFC 6476", + abstract={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]}, + keywords="authenticated data", + doi="10.17487/RFC6476", + } + +@misc{rfc6477, + author="A. Melnikov and G. Lunt", + title="{Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail}", + howpublished="RFC 6477 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6477", + pages="1--21", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6477.txt", + key="RFC 6477", + abstract={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.}, + doi="10.17487/RFC6477", + } + +@misc{rfc6478, + author="L. Martini and G. Swallow and G. Heron and M. Bocci", + title="{Pseudowire Status for Static Pseudowires}", + howpublished="RFC 6478 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6478", + pages="1--13", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7274", +url="https://www.rfc-editor.org/rfc/rfc6478.txt", + key="RFC 6478", + abstract={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]}, + keywords="", + doi="10.17487/RFC6478", + } + +@misc{rfc6479, + author="X. Zhang and T. Tsou", + title="{IPsec Anti-Replay Algorithm without Bit Shifting}", + howpublished="RFC 6479 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6479", + pages="1--9", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6479.txt", + key="RFC 6479", + abstract={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.}, + doi="10.17487/RFC6479", + } + +@misc{rfc6480, + author="M. Lepinski and S. Kent", + title="{An Infrastructure to Support Secure Internet Routing}", + howpublished="RFC 6480 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6480", + pages="1--24", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6480.txt", + key="RFC 6480", + abstract={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.}, + keywords="RPKI, BGP, ROA", + doi="10.17487/RFC6480", + } + +@misc{rfc6481, + author="G. Huston and R. Loomans and G. Michaelson", + title="{A Profile for Resource Certificate Repository Structure}", + howpublished="RFC 6481 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6481", + pages="1--15", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6481.txt", + key="RFC 6481", + abstract={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]}, + keywords="rpki, Resource Public Key Infrastructure", + doi="10.17487/RFC6481", + } + +@misc{rfc6482, + author="M. Lepinski and S. Kent and D. Kong", + title="{A Profile for Route Origin Authorizations (ROAs)}", + howpublished="RFC 6482 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6482", + pages="1--9", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6482.txt", + key="RFC 6482", + abstract={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]}, + keywords="RPKI, BGP", + doi="10.17487/RFC6482", + } + +@misc{rfc6483, + author="G. Huston and G. Michaelson", + title="{Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)}", + howpublished="RFC 6483 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6483", + pages="1--8", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6483.txt", + key="RFC 6483", + abstract={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.}, + keywords="rpki, bgp, Resource Public Key Infrastructure", + doi="10.17487/RFC6483", + } + +@misc{rfc6484, + author="S. Kent and D. Kong and K. Seo and R. Watro", + title="{Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 6484 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6484", + pages="1--35", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6484.txt", + key="RFC 6484", + abstract={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.}, + keywords="Certification Practice Statement, CPS", + doi="10.17487/RFC6484", + } + +@misc{rfc6485, + author="G. Huston", + title="{The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 6485 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6485", + pages="1--6", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7935", +url="https://www.rfc-editor.org/rfc/rfc6485.txt", + key="RFC 6485", + abstract={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]}, + keywords="", + doi="10.17487/RFC6485", + } + +@misc{rfc6486, + author="R. Austein and G. Huston and S. Kent and M. Lepinski", + title="{Manifests for the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 6486 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6486", + pages="1--19", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6486.txt", + key="RFC 6486", + abstract={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]}, + keywords="", + doi="10.17487/RFC6486", + } + +@misc{rfc6487, + author="G. Huston and G. Michaelson and R. Loomans", + title="{A Profile for X.509 PKIX Resource Certificates}", + howpublished="RFC 6487 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6487", + pages="1--32", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7318, 8209", +url="https://www.rfc-editor.org/rfc/rfc6487.txt", + key="RFC 6487", + abstract={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]}, + keywords="rpki, Resource Public Key Infrastructure, Internet Number Resources, INR", + doi="10.17487/RFC6487", + } + +@misc{rfc6488, + author="M. Lepinski and A. Chi and S. Kent", + title="{Signed Object Template for the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 6488 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6488", + pages="1--13", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6488.txt", + key="RFC 6488", + abstract={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]}, + keywords="ROA, manifest, GhostBusters", + doi="10.17487/RFC6488", + } + +@misc{rfc6489, + author="G. Huston and G. Michaelson and S. Kent", + title="{Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 6489 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6489", + pages="1--10", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6489.txt", + key="RFC 6489", + abstract={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.}, + keywords="RPKI", + doi="10.17487/RFC6489", + } + +@misc{rfc6490, + author="G. Huston and S. Weiler and G. Michaelson and S. Kent", + title="{Resource Public Key Infrastructure (RPKI) Trust Anchor Locator}", + howpublished="RFC 6490 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6490", + pages="1--7", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7730", +url="https://www.rfc-editor.org/rfc/rfc6490.txt", + key="RFC 6490", + abstract={This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). [STANDARDS-TRACK]}, + keywords="tal", + doi="10.17487/RFC6490", + } + +@misc{rfc6491, + author="T. Manderson and L. Vegoda and S. Kent", + title="{Resource Public Key Infrastructure (RPKI) Objects Issued by IANA}", + howpublished="RFC 6491 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6491", + pages="1--12", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6491.txt", + key="RFC 6491", + abstract={This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. [STANDARDS-TRACK]}, + keywords="sidr, rpki, iana, as0, as 0, roa", + doi="10.17487/RFC6491", + } + +@misc{rfc6492, + author="G. Huston and R. Loomans and B. Ellacott and R. Austein", + title="{A Protocol for Provisioning Resource Certificates}", + howpublished="RFC 6492 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6492", + pages="1--32", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6492.txt", + key="RFC 6492", + abstract={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]}, + keywords="RPKI", + doi="10.17487/RFC6492", + } + +@misc{rfc6493, + author="R. Bush", + title="{The Resource Public Key Infrastructure (RPKI) Ghostbusters Record}", + howpublished="RFC 6493 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6493", + pages="1--8", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6493.txt", + key="RFC 6493", + abstract={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]}, + keywords="RPKI, Resource Certificate, Human Contact, vCard", + doi="10.17487/RFC6493", + } + +@misc{rfc6494, + author="R. Gagliano and S. Krishnan and A. Kukec", + title="{Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)}", + howpublished="RFC 6494 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6494", + pages="1--12", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6494.txt", + key="RFC 6494", + abstract={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]}, + keywords="RPKI, ND", + doi="10.17487/RFC6494", + } + +@misc{rfc6495, + author="R. Gagliano and S. Krishnan and A. Kukec", + title="{Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields}", + howpublished="RFC 6495 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6495", + pages="1--5", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6495.txt", + key="RFC 6495", + abstract={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]}, + keywords="", + doi="10.17487/RFC6495", + } + +@misc{rfc6496, + author="S. Krishnan and J. Laganier and M. Bonola and A. Garcia-Martinez", + title="{Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)}", + howpublished="RFC 6496 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6496", + pages="1--24", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6496.txt", + key="RFC 6496", + abstract={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.}, + keywords="SPND, CGA, Mobile IPv6, MIPv6, Proxy Mobile IPv6, PMIPv6", + doi="10.17487/RFC6496", + } + +@misc{rfc6497, + author="M. Davis and A. Phillips and Y. Umaoka and C. Falk", + title="{BCP 47 Extension T - Transformed Content}", + howpublished="RFC 6497 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6497", + pages="1--15", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6497.txt", + key="RFC 6497", + abstract={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.}, + keywords="locale", + doi="10.17487/RFC6497", + } + +@misc{rfc6498, + author="J. Stone and R. Kumar and F. Andreasen", + title="{Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package}", + howpublished="RFC 6498 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6498", + pages="1--47", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6498.txt", + key="RFC 6498", + abstract={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.}, + doi="10.17487/RFC6498", + } + +@misc{rfc6501, + author="O. Novo and G. Camarillo and D. Morgan and J. Urpalainen", + title="{Conference Information Data Model for Centralized Conferencing (XCON)}", + howpublished="RFC 6501 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6501", + pages="1--94", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6501.txt", + key="RFC 6501", + abstract={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]}, + keywords="", + doi="10.17487/RFC6501", + } + +@misc{rfc6502, + author="G. Camarillo and S. Srinivasan and R. Even and J. Urpalainen", + title="{Conference Event Package Data Format Extension for Centralized Conferencing (XCON)}", + howpublished="RFC 6502 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6502", + pages="1--14", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6502.txt", + key="RFC 6502", + abstract={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]}, + keywords="", + doi="10.17487/RFC6502", + } + +@misc{rfc6503, + author="M. Barnes and C. Boulton and S. Romano and H. Schulzrinne", + title="{Centralized Conferencing Manipulation Protocol}", + howpublished="RFC 6503 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6503", + pages="1--119", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6503.txt", + key="RFC 6503", + abstract={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]}, + keywords="conference user, ad hoc conference, sidebar conference, scheduled conference", + doi="10.17487/RFC6503", + } + +@misc{rfc6504, + author="M. Barnes and L. Miniero and R. Presta and S P. Romano", + title="{Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples}", + howpublished="RFC 6504 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6504", + pages="1--78", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6504.txt", + key="RFC 6504", + abstract={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.}, + doi="10.17487/RFC6504", + } + +@misc{rfc6505, + author="S. McGlashan and T. Melanchuk and C. Boulton", + title="{A Mixer Control Package for the Media Control Channel Framework}", + howpublished="RFC 6505 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6505", + pages="1--89", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6505.txt", + key="RFC 6505", + abstract={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]}, + keywords="conference mixer", + doi="10.17487/RFC6505", + } + +@misc{rfc6506, + author="M. Bhatia and V. Manral and A. Lindem", + title="{Supporting Authentication Trailer for OSPFv3}", + howpublished="RFC 6506 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6506", + pages="1--20", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7166", +url="https://www.rfc-editor.org/rfc/rfc6506.txt", + key="RFC 6506", + abstract={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]}, + keywords="Routing security", + doi="10.17487/RFC6506", + } + +@misc{rfc6507, + author="M. Groves", + title="{Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)}", + howpublished="RFC 6507 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6507", + pages="1--17", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6507.txt", + key="RFC 6507", + abstract={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.}, + doi="10.17487/RFC6507", + } + +@misc{rfc6508, + author="M. Groves", + title="{Sakai-Kasahara Key Encryption (SAKKE)}", + howpublished="RFC 6508 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6508", + pages="1--21", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6508.txt", + key="RFC 6508", + abstract={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.}, + doi="10.17487/RFC6508", + } + +@misc{rfc6509, + author="M. Groves", + title="{MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)}", + howpublished="RFC 6509 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6509", + pages="1--21", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6509.txt", + key="RFC 6509", + abstract={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.}, + doi="10.17487/RFC6509", + } + +@misc{rfc6510, + author="L. Berger and G. Swallow", + title="{Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects}", + howpublished="RFC 6510 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6510", + pages="1--8", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6510.txt", + key="RFC 6510", + abstract={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]}, + keywords="", + doi="10.17487/RFC6510", + } + +@misc{rfc6511, + author="Z. Ali and G. Swallow and R. Aggarwal", + title="{Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths}", + howpublished="RFC 6511 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6511", + pages="1--10", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6511.txt", + key="RFC 6511", + abstract={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]}, + keywords="", + doi="10.17487/RFC6511", + } + +@misc{rfc6512, + author="IJ. Wijnands and E. Rosen and M. Napierala and N. Leymann", + title="{Using Multipoint LDP When the Backbone Has No Route to the Root}", + howpublished="RFC 6512 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6512", + pages="1--12", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6512.txt", + key="RFC 6512", + abstract={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]}, + keywords="", + doi="10.17487/RFC6512", + } + +@misc{rfc6513, + author="E. {Rosen (Ed.)} and R. {Aggarwal (Ed.)}", + title="{Multicast in MPLS/BGP IP VPNs}", + howpublished="RFC 6513 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6513", + pages="1--88", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7582, 7900, 7988", +url="https://www.rfc-editor.org/rfc/rfc6513.txt", + key="RFC 6513", + abstract={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]}, + keywords="", + doi="10.17487/RFC6513", + } + +@misc{rfc6514, + author="R. Aggarwal and E. Rosen and T. Morin and Y. Rekhter", + title="{BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs}", + howpublished="RFC 6514 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6514", + pages="1--59", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 6515, 6625, 7385, 7441, 7582, 7899, 7900, 7902, 7988", +url="https://www.rfc-editor.org/rfc/rfc6514.txt", + key="RFC 6514", + abstract={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]}, + keywords="", + doi="10.17487/RFC6514", + } + +@misc{rfc6515, + author="R. Aggarwal and E. Rosen", + title="{IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN}", + howpublished="RFC 6515 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6515", + pages="1--8", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6515.txt", + key="RFC 6515", + abstract={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. Speci fic cases are explained in detail. This document updates RFC 6514. [STANDARDS-TRACK]}, + keywords="mvpn, mcast-vpn, multicast-vpn", + doi="10.17487/RFC6515", + } + +@misc{rfc6516, + author="Y. Cai and E. {Rosen (Ed.)} and I. Wijnands", + title="{IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages}", + howpublished="RFC 6516 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6516", + pages="1--6", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6516.txt", + key="RFC 6516", + abstract={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]}, + keywords="", + doi="10.17487/RFC6516", + } + +@misc{rfc6517, + author="T. {Morin (Ed.)} and B. {Niven-Jenkins (Ed.)} and Y. Kamite and R. Zhang and N. Leymann and N. Bitar", + title="{Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution}", + howpublished="RFC 6517 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6517", + pages="1--41", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6517.txt", + key="RFC 6517", + abstract={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. 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.}, + keywords="mpls, vpn, multicast, l3vpn, bgp, pim, p2mp, ldp, rsvp-te", + doi="10.17487/RFC6517", + } + +@misc{rfc6518, + author="G. Lebovitz and M. Bhatia", + title="{Keying and Authentication for Routing Protocols (KARP) Design Guidelines}", + howpublished="RFC 6518 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6518", + pages="1--30", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6518.txt", + key="RFC 6518", + abstract={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.}, + keywords="MAC, hash, security, securing, secure, authorization, protection, harden, hardening, infrastructure, router, crypto, cryptography, cryptographic, roadmap, guide, guideline, message, framework, key, keys, management, protocol, KMP, key management protocol,", + doi="10.17487/RFC6518", + } + +@misc{rfc6519, + author="R. Maglione and A. Durand", + title="{RADIUS Extensions for Dual-Stack Lite}", + howpublished="RFC 6519 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6519", + pages="1--11", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6519.txt", + key="RFC 6519", + abstract={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]}, + keywords="IPv6, tunnel, attribute", + doi="10.17487/RFC6519", + } + +@misc{rfc6520, + author="R. Seggelmann and M. Tuexen and M. Williams", + title="{Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension}", + howpublished="RFC 6520 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6520", + pages="1--9", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8447", +url="https://www.rfc-editor.org/rfc/rfc6520.txt", + key="RFC 6520", + abstract={This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. 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]}, + keywords="tls/dtls", + doi="10.17487/RFC6520", + } + +@misc{rfc6521, + author="A. Makela and J. Korhonen", + title="{Home Agent-Assisted Route Optimization between Mobile IPv4 Networks}", + howpublished="RFC 6521 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6521", + pages="1--53", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6521.txt", + key="RFC 6521", + abstract={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.}, + keywords="mobile router, mobile network prefix, correspondent router", + doi="10.17487/RFC6521", + } + +@misc{rfc6522, + author="M. {Kucherawy (Ed.)}", + title="{The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages}", + howpublished="RFC 6522 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="6522", + pages="1--9", + year=2012, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6533", +url="https://www.rfc-editor.org/rfc/rfc6522.txt", + key="RFC 6522", + abstract={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. 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]}, + keywords="MIME, Multipurpose Internet Mail Extensions", + doi="10.17487/RFC6522", + } + +@misc{rfc6525, + author="R. Stewart and M. Tuexen and P. Lei", + title="{Stream Control Transmission Protocol (SCTP) Stream Reconfiguration}", + howpublished="RFC 6525 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6525", + pages="1--34", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6525.txt", + key="RFC 6525", + abstract={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]}, + keywords="", + doi="10.17487/RFC6525", + } + +@misc{rfc6526, + author="B. Claise and P. Aitken and A. Johnson and G. Muenz", + title="{IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream}", + howpublished="RFC 6526 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6526", + pages="1--23", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6526.txt", + key="RFC 6526", + abstract={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). 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]}, + keywords="", + doi="10.17487/RFC6526", + } + +@misc{rfc6527, + author="K. Tata", + title="{Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)}", + howpublished="RFC 6527 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6527", + pages="1--31", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6527.txt", + key="RFC 6527", + abstract={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]}, + keywords="management information base", + doi="10.17487/RFC6527", + } + +@misc{rfc6528, + author="F. Gont and S. Bellovin", + title="{Defending against Sequence Number Attacks}", + howpublished="RFC 6528 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6528", + pages="1--12", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6528.txt", + key="RFC 6528", + abstract={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]}, + keywords="TCP security, TCP Sequence Numbers, Sequence Number Randomization, obfuscation, TCP vulnerabilities", + doi="10.17487/RFC6528", + } + +@misc{rfc6529, + author="A. McKenzie and S. Crocker", + title="{Host/Host Protocol for the ARPA Network}", + howpublished="RFC 6529 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6529", + pages="1--34", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6529.txt", + key="RFC 6529", + abstract={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.}, + doi="10.17487/RFC6529", + } + +@misc{rfc6530, + author="J. Klensin and Y. Ko", + title="{Overview and Framework for Internationalized Email}", + howpublished="RFC 6530 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6530", + pages="1--26", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6530.txt", + key="RFC 6530", + abstract={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]}, + keywords="SMTP, Email I18n, Internationalization, SMTPUTF8", + doi="10.17487/RFC6530", + } + +@misc{rfc6531, + author="J. Yao and W. Mao", + title="{SMTP Extension for Internationalized Email}", + howpublished="RFC 6531 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6531", + pages="1--18", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6531.txt", + key="RFC 6531", + abstract={This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]}, + keywords="SMTP, Email I18n, Internationalization, SMTPUTF8", + doi="10.17487/RFC6531", + } + +@misc{rfc6532, + author="A. Yang and S. Steele and N. Freed", + title="{Internationalized Email Headers}", + howpublished="RFC 6532 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6532", + pages="1--11", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6532.txt", + key="RFC 6532", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC6532", + } + +@misc{rfc6533, + author="T. {Hansen (Ed.)} and C. Newman and A. Melnikov", + title="{Internationalized Delivery Status and Disposition Notifications}", + howpublished="RFC 6533 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6533", + pages="1--19", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6533.txt", + key="RFC 6533", + abstract={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. This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK]}, + keywords="dsn", + doi="10.17487/RFC6533", + } + +@misc{rfc6534, + author="N. Duffield and A. Morton and J. Sommers", + title="{Loss Episode Metrics for IP Performance Metrics (IPPM)}", + howpublished="RFC 6534 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6534", + pages="1--21", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6534.txt", + key="RFC 6534", + abstract={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]}, + keywords="", + doi="10.17487/RFC6534", + } + +@misc{rfc6535, + author="B. Huang and H. Deng and T. Savolainen", + title="{Dual-Stack Hosts Using ``Bump-in-the-Host'' (BIH)}", + howpublished="RFC 6535 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6535", + pages="1--25", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6535.txt", + key="RFC 6535", + abstract={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]}, + keywords="NAT, NAT46, DNS, DNS46, translation, IPv4, applications, IPv6, ENR", + doi="10.17487/RFC6535", + } + +@misc{rfc6536, + author="A. Bierman and M. Bjorklund", + title="{Network Configuration Protocol (NETCONF) Access Control Model}", + howpublished="RFC 6536 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6536", + pages="1--49", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8341", +url="https://www.rfc-editor.org/rfc/rfc6536.txt", + key="RFC 6536", + abstract={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]}, + keywords="NETCONF, YANG, XML", + doi="10.17487/RFC6536", + } + +@misc{rfc6537, + author="J. Ahrenholz", + title="{Host Identity Protocol Distributed Hash Table Interface}", + howpublished="RFC 6537 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6537", + pages="1--20", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6537.txt", + key="RFC 6537", + abstract={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.}, + keywords="HIP, Host Identity Protocol, DHT, DIstributed Hash Table, HIT, Host Identity Tag, resolution, service", + doi="10.17487/RFC6537", + } + +@misc{rfc6538, + author="T. Henderson and A. Gurtov", + title="{The Host Identity Protocol (HIP) Experiment Report}", + howpublished="RFC 6538 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6538", + pages="1--35", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6538.txt", + key="RFC 6538", + abstract={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.}, + keywords="Security, ID/locator split, IPsec, Research", + doi="10.17487/RFC6538", + } + +@misc{rfc6539, + author="V. Cakulev and G. Sundaram and I. Broustis", + title="{IBAKE: Identity-Based Authenticated Key Exchange}", + howpublished="RFC 6539 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6539", + pages="1--13", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6539.txt", + key="RFC 6539", + abstract={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.}, + keywords="ibe, identity based encryption", + doi="10.17487/RFC6539", + } + +@misc{rfc6540, + author="W. George and C. Donley and C. Liljenstolpe and L. Howard", + title="{IPv6 Support Required for All IP-Capable Nodes}", + howpublished="RFC 6540 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6540", + pages="1--6", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6540.txt", + key="RFC 6540", + abstract={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.}, + keywords="IPv4, requirement", + doi="10.17487/RFC6540", + } + +@misc{rfc6541, + author="M. Kucherawy", + title="{DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures}", + howpublished="RFC 6541 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6541", + pages="1--16", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6541.txt", + key="RFC 6541", + abstract={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.}, + keywords="Authentication, Reputation", + doi="10.17487/RFC6541", + } + +@misc{rfc6542, + author="S. Emery", + title="{Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility}", + howpublished="RFC 6542 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6542", + pages="1--6", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6542.txt", + key="RFC 6542", + abstract={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]}, + keywords="", + doi="10.17487/RFC6542", + } + +@misc{rfc6543, + author="S. Gundavelli", + title="{Reserved IPv6 Interface Identifier for Proxy Mobile IPv6}", + howpublished="RFC 6543 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6543", + pages="1--5", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6543.txt", + key="RFC 6543", + abstract={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]}, + keywords="", + doi="10.17487/RFC6543", + } + +@misc{rfc6544, + author="J. Rosenberg and A. Keranen and B. B. Lowekamp and A. B. Roach", + title="{TCP Candidates with Interactive Connectivity Establishment (ICE)}", + howpublished="RFC 6544 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6544", + pages="1--29", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6544.txt", + key="RFC 6544", + abstract={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]}, + keywords="ICE, TCP, NAT, NAT traversal", + doi="10.17487/RFC6544", + } + +@misc{rfc6545, + author="K. Moriarty", + title="{Real-time Inter-network Defense (RID)}", + howpublished="RFC 6545 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6545", + pages="1--84", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6545.txt", + key="RFC 6545", + abstract={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 obsole tes RFC 6045. [STANDARDS-TRACK]}, + keywords="incident response, incident coordination, incident handling, incident communication", + doi="10.17487/RFC6545", + } + +@misc{rfc6546, + author="B. Trammell", + title="{Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS}", + howpublished="RFC 6546 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6546", + pages="1--8", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6546.txt", + key="RFC 6546", + abstract={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]}, + keywords="Coordinated Incident Response, CSIRT, Incident Object Description Exchange Format, IODEF", + doi="10.17487/RFC6546", + } + +@misc{rfc6547, + author="W. George", + title="{RFC 3627 to Historic Status}", + howpublished="RFC 6547 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6547", + pages="1--3", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6547.txt", + key="RFC 6547", + abstract={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.}, + keywords="IPv6, /127, point-to-point address, inter-router links", + doi="10.17487/RFC6547", + } + +@misc{rfc6548, + author="N. {Brownlee (Ed.)} and IAB", + title="{Independent Submission Editor Model}", + howpublished="RFC 6548 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6548", + pages="1--5", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6548.txt", + key="RFC 6548", + abstract={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.}, + keywords="Independent Stream Editor", + doi="10.17487/RFC6548", + } + +@misc{rfc6549, + author="A. Lindem and A. Roy and S. Mirtorabi", + title="{OSPFv2 Multi-Instance Extensions}", + howpublished="RFC 6549 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6549", + pages="1--9", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6549.txt", + key="RFC 6549", + abstract={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. 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. This document updates RFC 2328. [STANDARDS-TRACK]}, + keywords="Instance ID", + doi="10.17487/RFC6549", + } + +@misc{rfc6550, + author="T. {Winter (Ed.)} and P. {Thubert (Ed.)} and A. Brandt and J. Hui and R. Kelsey and P. Levis and K. Pister and R. Struik and JP. Vasseur and R. Alexander", + title="{RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks}", + howpublished="RFC 6550 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6550", + pages="1--157", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6550.txt", + key="RFC 6550", + abstract={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]}, + keywords="WSN for Wireless Sensor Network, L3 Mesh for Layer 3 Mesh Network, Routing Protocol, Subnet Routing, Distance Vector, Objective Function, DAG for Directed Acyclic Graph", + doi="10.17487/RFC6550", + } + +@misc{rfc6551, + author="JP. {Vasseur (Ed.)} and M. {Kim (Ed.)} and K. Pister and N. Dejean and D. Barthel", + title="{Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks}", + howpublished="RFC 6551 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6551", + pages="1--30", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6551.txt", + key="RFC 6551", + abstract={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]}, + keywords="RPL, ROLL, LLN, Constrained based routing,", + doi="10.17487/RFC6551", + } + +@misc{rfc6552, + author="P. {Thubert (Ed.)}", + title="{Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)}", + howpublished="RFC 6552 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6552", + pages="1--14", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6552.txt", + key="RFC 6552", + abstract={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. 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]}, + keywords="WSN for Wireless Sensor Network, L3 Mesh for Layer 3 Mesh Network, Routing Protocol, Subnet Routing, Distance Vector, Objective Function, DAG for Directed Acyclic Graph, RPL", + doi="10.17487/RFC6552", + } + +@misc{rfc6553, + author="J. Hui and JP. Vasseur", + title="{The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams}", + howpublished="RFC 6553 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6553", + pages="1--9", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6553.txt", + key="RFC 6553", + abstract={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]}, + keywords="LLN, LLNs, Trickle", + doi="10.17487/RFC6553", + } + +@misc{rfc6554, + author="J. Hui and JP. Vasseur and D. Culler and V. Manral", + title="{An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)}", + howpublished="RFC 6554 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6554", + pages="1--13", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6554.txt", + key="RFC 6554", + abstract={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]}, + keywords="LLN, LLNs", + doi="10.17487/RFC6554", + } + +@misc{rfc6555, + author="D. Wing and A. Yourtchenko", + title="{Happy Eyeballs: Success with Dual-Stack Hosts}", + howpublished="RFC 6555 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6555", + pages="1--15", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8305", +url="https://www.rfc-editor.org/rfc/rfc6555.txt", + key="RFC 6555", + abstract={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]}, + keywords="", + doi="10.17487/RFC6555", + } + +@misc{rfc6556, + author="F. Baker", + title="{Testing Eyeball Happiness}", + howpublished="RFC 6556 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6556", + pages="1--10", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6556.txt", + key="RFC 6556", + abstract={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.}, + keywords="test methodology, IPv4, IPv6, session startup, metrics", + doi="10.17487/RFC6556", + } + +@misc{rfc6557, + author="E. Lear and P. Eggert", + title="{Procedures for Maintaining the Time Zone Database}", + howpublished="RFC 6557 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6557", + pages="1--9", + year=2012, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6557.txt", + key="RFC 6557", + abstract={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.}, + keywords="", + doi="10.17487/RFC6557", + } + +@misc{rfc6558, + author="A. Melnikov and B. Leiba and K. Li", + title="{Sieve Extension for Converting Messages before Delivery}", + howpublished="RFC 6558 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6558", + pages="1--8", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6558.txt", + key="RFC 6558", + abstract={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]}, + keywords="Sieve, CONVERT", + doi="10.17487/RFC6558", + } + +@misc{rfc6559, + author="D. Farinacci and IJ. Wijnands and S. Venaas and M. Napierala", + title="{A Reliable Transport Mechanism for PIM}", + howpublished="RFC 6559 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6559", + pages="1--29", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6559.txt", + key="RFC 6559", + abstract={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.}, + keywords="", + doi="10.17487/RFC6559", + } + +@misc{rfc6560, + author="G. Richards", + title="{One-Time Password (OTP) Pre-Authentication}", + howpublished="RFC 6560 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6560", + pages="1--43", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6560.txt", + key="RFC 6560", + abstract={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]}, + keywords="", + doi="10.17487/RFC6560", + } + +@misc{rfc6561, + author="J. Livingood and N. Mody and M. O'Reirdan", + title="{Recommendations for the Remediation of Bots in ISP Networks}", + howpublished="RFC 6561 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6561", + pages="1--29", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6561.txt", + key="RFC 6561", + abstract={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.}, + keywords="ISP, Internet Service Provider, Bot, Botnet, Remediation, malware, notification", + doi="10.17487/RFC6561", + } + +@misc{rfc6562, + author="C. Perkins and JM. Valin", + title="{Guidelines for the Use of Variable Bit Rate Audio with Secure RTP}", + howpublished="RFC 6562 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6562", + pages="1--6", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6562.txt", + key="RFC 6562", + abstract={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]}, + keywords="vbr", + doi="10.17487/RFC6562", + } + +@misc{rfc6563, + author="S. Jiang and D. Conrad and B. Carpenter", + title="{Moving A6 to Historic Status}", + howpublished="RFC 6563 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6563", + pages="1--8", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6563.txt", + key="RFC 6563", + abstract={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.}, + doi="10.17487/RFC6563", + } + +@misc{rfc6564, + author="S. Krishnan and J. Woodyatt and E. Kline and J. Hoagland and M. Bhatia", + title="{A Uniform Format for IPv6 Extension Headers}", + howpublished="RFC 6564 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6564", + pages="1--6", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6564.txt", + key="RFC 6564", + abstract={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]}, + keywords="", + doi="10.17487/RFC6564", + } + +@misc{rfc6565, + author="P. Pillay-Esnault and P. Moyer and J. Doyle and E. Ertekin and M. Lundberg", + title="{OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol}", + howpublished="RFC 6565 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6565", + pages="1--20", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6565.txt", + key="RFC 6565", + abstract={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]}, + keywords="L3VPN, BGP/MPLS, VPN", + doi="10.17487/RFC6565", + } + +@misc{rfc6566, + author="Y. {Lee (Ed.)} and G. {Bernstein (Ed.)} and D. Li and G. Martinelli", + title="{A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments}", + howpublished="RFC 6566 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6566", + pages="1--31", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6566.txt", + key="RFC 6566", + abstract={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. 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; rat her, 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.}, + doi="10.17487/RFC6566", + } + +@misc{rfc6567, + author="A. Johnston and L. Liess", + title="{Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP}", + howpublished="RFC 6567 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6567", + pages="1--11", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6567.txt", + key="RFC 6567", + abstract={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.}, + doi="10.17487/RFC6567", + } + +@misc{rfc6568, + author="E. Kim and D. Kaspar and JP. Vasseur", + title="{Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}", + howpublished="RFC 6568 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6568", + pages="1--28", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6568.txt", + key="RFC 6568", + abstract={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.}, + doi="10.17487/RFC6568", + } + +@misc{rfc6569, + author="JM. Valin and S. Borilin and K. Vos and C. Montgomery and R. Chen", + title="{Guidelines for Development of an Audio Codec within the IETF}", + howpublished="RFC 6569 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6569", + pages="1--14", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6569.txt", + key="RFC 6569", + abstract={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.}, + keywords="audio codec, speech codec", + doi="10.17487/RFC6569", + } + +@misc{rfc6570, + author="J. Gregorio and R. Fielding and M. Hadley and M. Nottingham and D. Orchard", + title="{URI Template}", + howpublished="RFC 6570 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6570", + pages="1--34", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6570.txt", + key="RFC 6570", + abstract={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]}, + keywords="template, Uniform Resource Identifier, URI, URI Template, Internationalized Resource Identifier, IRI, IRI Template", + doi="10.17487/RFC6570", + } + +@misc{rfc6571, + author="C. {Filsfils (Ed.)} and P. {Francois (Ed.)} and M. Shand and B. Decraene and J. Uttaro and N. Leymann and M. Horneffer", + title="{Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks}", + howpublished="RFC 6571 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6571", + pages="1--35", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6571.txt", + key="RFC 6571", + abstract={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.}, + keywords="IP Fast Reroute, Routing Convergence, Network Topology, IS-IS, OSPF", + doi="10.17487/RFC6571", + } + +@misc{rfc6572, + author="F. Xia and B. Sarikaya and J. {Korhonen (Ed.)} and S. Gundavelli and D. Damic", + title="{RADIUS Support for Proxy Mobile IPv6}", + howpublished="RFC 6572 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6572", + pages="1--36", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8044", +url="https://www.rfc-editor.org/rfc/rfc6572.txt", + key="RFC 6572", + abstract={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]}, + keywords="", + doi="10.17487/RFC6572", + } + +@misc{rfc6573, + author="M. Amundsen", + title="{The Item and Collection Link Relations}", + howpublished="RFC 6573 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6573", + pages="1--5", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6573.txt", + key="RFC 6573", + abstract={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.}, + doi="10.17487/RFC6573", + } + +@misc{rfc6574, + author="H. Tschofenig and J. Arkko", + title="{Report from the Smart Object Workshop}", + howpublished="RFC 6574 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6574", + pages="1--32", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6574.txt", + key="RFC 6574", + abstract={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. 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.}, + keywords="Smart Objects, Internet of Things", + doi="10.17487/RFC6574", + } + +@misc{rfc6575, + author="H. {Shah (Ed.)} and E. {Rosen (Ed.)} and G. {Heron (Ed.)} and V. {Kompella (Ed.)}", + title="{Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs}", + howpublished="RFC 6575 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6575", + pages="1--28", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6575.txt", + key="RFC 6575", + abstract={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 wh en the CEs run a routing protocol between them, as long as the routing protocol runs over IP. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC6575", + } + +@misc{rfc6576, + author="R. {Geib (Ed.)} and A. Morton and R. Fardid and A. Steinmitz", + title="{IP Performance Metrics (IPPM) Standard Advancement Testing}", + howpublished="RFC 6576 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6576", + pages="1--37", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6576.txt", + key="RFC 6576", + abstract={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.}, + keywords="inter-operability, equivalence, measurement, compliance, metric", + doi="10.17487/RFC6576", + } + +@misc{rfc6577, + author="M. Kucherawy", + title="{Authentication-Results Registration Update for Sender Policy Framework (SPF) Results}", + howpublished="RFC 6577 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6577", + pages="1--5", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7001", +url="https://www.rfc-editor.org/rfc/rfc6577.txt", + key="RFC 6577", + abstract={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]}, + keywords="SPF, Authentication", + doi="10.17487/RFC6577", + } + +@misc{rfc6578, + author="C. Daboo and A. Quillaud", + title="{Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)}", + howpublished="RFC 6578 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6578", + pages="1--29", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6578.txt", + key="RFC 6578", + abstract={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]}, + keywords="sync-collection, sync-token", + doi="10.17487/RFC6578", + } + +@misc{rfc6579, + author="M. Yevstifeyev", + title="{The 'disclosure' Link Relation Type}", + howpublished="RFC 6579 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6579", + pages="1--5", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6579.txt", + key="RFC 6579", + abstract={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]}, + doi="10.17487/RFC6579", + } + +@misc{rfc6580, + author="M. Ko and D. Black", + title="{IANA Registries for the Remote Direct Data Placement (RDDP) Protocols}", + howpublished="RFC 6580 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6580", + pages="1--10", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6580.txt", + key="RFC 6580", + abstract={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]}, + keywords="", + doi="10.17487/RFC6580", + } + +@misc{rfc6581, + author="A. {Kanevsky (Ed.)} and C. {Bestler (Ed.)} and R. Sharp and S. Wise", + title="{Enhanced Remote Direct Memory Access (RDMA) Connection Establishment}", + howpublished="RFC 6581 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6581", + pages="1--25", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6581.txt", + key="RFC 6581", + abstract={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]}, + keywords="", + doi="10.17487/RFC6581", + } + +@misc{rfc6582, + author="T. Henderson and S. Floyd and A. Gurtov and Y. Nishida", + title="{The NewReno Modification to TCP's Fast Recovery Algorithm}", + howpublished="RFC 6582 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6582", + pages="1--16", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6582.txt", + key="RFC 6582", + abstract={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]}, + keywords="congestion avoidance, congestion control, fast retransmit", + doi="10.17487/RFC6582", + } + +@misc{rfc6583, + author="I. Gashinsky and J. Jaeggli and W. Kumari", + title="{Operational Neighbor Discovery Problems}", + howpublished="RFC 6583 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6583", + pages="1--12", + year=2012, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6583.txt", + key="RFC 6583", + abstract={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. 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]}, + doi="10.17487/RFC6583", + } + +@misc{rfc6584, + author="V. Roca", + title="{Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols}", + howpublished="RFC 6584 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6584", + pages="1--30", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6584.txt", + key="RFC 6584", + abstract={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]}, + keywords="TESLA, FLUTE", + doi="10.17487/RFC6584", + } + +@misc{rfc6585, + author="M. Nottingham and R. Fielding", + title="{Additional HTTP Status Codes}", + howpublished="RFC 6585 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6585", + pages="1--10", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6585.txt", + key="RFC 6585", + abstract={This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]}, + keywords="Hypertext Transfer Protocol", + doi="10.17487/RFC6585", + } + +@misc{rfc6586, + author="J. Arkko and A. Keranen", + title="{Experiences from an IPv6-Only Network}", + howpublished="RFC 6586 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6586", + pages="1--21", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6586.txt", + key="RFC 6586", + abstract={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.}, + keywords="IPv6, NAT64", + doi="10.17487/RFC6586", + } + +@misc{rfc6587, + author="R. Gerhards and C. Lonvick", + title="{Transmission of Syslog Messages over TCP}", + howpublished="RFC 6587 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6587", + pages="1--11", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6587.txt", + key="RFC 6587", + abstract={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.}, + keywords="SYSLOG, SYSLOG transport TCP", + doi="10.17487/RFC6587", + } + +@misc{rfc6588, + author="C. Ishikawa", + title="{A URN Namespace for ucode}", + howpublished="RFC 6588 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6588", + pages="1--8", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6588.txt", + key="RFC 6588", + abstract={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.}, + doi="10.17487/RFC6588", + } + +@misc{rfc6589, + author="J. Livingood", + title="{Considerations for Transitioning Content to IPv6}", + howpublished="RFC 6589 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6589", + pages="1--27", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6589.txt", + key="RFC 6589", + abstract={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.}, + doi="10.17487/RFC6589", + } + +@misc{rfc6590, + author="J. {Falk (Ed.)} and M. {Kucherawy (Ed.)}", + title="{Redaction of Potentially Sensitive Data from Mail Abuse Reports}", + howpublished="RFC 6590 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6590", + pages="1--8", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6590.txt", + key="RFC 6590", + abstract={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]}, + keywords="ARF, MARF, feedback loop, spam reporting", + doi="10.17487/RFC6590", + } + +@misc{rfc6591, + author="H. Fontana", + title="{Authentication Failure Reporting Using the Abuse Reporting Format}", + howpublished="RFC 6591 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6591", + pages="1--16", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 6692", +url="https://www.rfc-editor.org/rfc/rfc6591.txt", + key="RFC 6591", + abstract={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]}, + keywords="auth, auth failure, dkim, spf, AFRF, ARF", + doi="10.17487/RFC6591", + } + +@misc{rfc6592, + author="C. Pignataro", + title="{The Null Packet}", + howpublished="RFC 6592 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6592", + pages="1--6", + year=2012, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6592.txt", + key="RFC 6592", + abstract={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.}, + doi="10.17487/RFC6592", + } + +@misc{rfc6593, + author="C. Pignataro and J. Clarke and G. Salgueiro", + title="{Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)}", + howpublished="RFC 6593 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6593", + pages="1--8", + year=2012, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6593.txt", + key="RFC 6593", + abstract={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. 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.}, + doi="10.17487/RFC6593", + } + +@misc{rfc6594, + author="O. Sury", + title="{Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records}", + howpublished="RFC 6594 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6594", + pages="1--9", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6594.txt", + key="RFC 6594", + abstract={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]}, + keywords="DNS, Domain Name System, SSHFP, SHA-256, Secure Shell, ECDSA", + doi="10.17487/RFC6594", + } + +@misc{rfc6595, + author="K. Wierenga and E. Lear and S. Josefsson", + title="{A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)}", + howpublished="RFC 6595 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6595", + pages="1--22", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6595.txt", + key="RFC 6595", + abstract={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]}, + keywords="Generic Security Service Application Program Interface, SAML 2.0", + doi="10.17487/RFC6595", + } + +@misc{rfc6596, + author="M. Ohye and J. Kupke", + title="{The Canonical Link Relation}", + howpublished="RFC 6596 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6596", + pages="1--8", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6596.txt", + key="RFC 6596", + abstract={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.}, + doi="10.17487/RFC6596", + } + +@misc{rfc6597, + author="J. {Downs (Ed.)} and J. {Arbeiter (Ed.)}", + title="{RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data}", + howpublished="RFC 6597 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6597", + pages="1--13", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6597.txt", + key="RFC 6597", + abstract={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]}, + keywords="KLV", + doi="10.17487/RFC6597", + } + +@misc{rfc6598, + author="J. Weil and V. Kuarsingh and C. Donley and C. Liljenstolpe and M. Azinger", + title="{IANA-Reserved IPv4 Prefix for Shared Address Space}", + howpublished="RFC 6598 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6598", + pages="1--11", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6598.txt", + key="RFC 6598", + abstract={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). 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. 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.}, + keywords="shared block, CGN, NAT, Carrier Grade NAT, private address space, service provider, address translation, non-globally routable, non-overlapping address space", + doi="10.17487/RFC6598", + } + +@misc{rfc6601, + author="G. {Ash (Ed.)} and D. McDysan", + title="{Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks}", + howpublished="RFC 6601 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6601", + pages="1--34", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6601.txt", + key="RFC 6601", + abstract={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 detai led 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.}, + doi="10.17487/RFC6601", + } + +@misc{rfc6602, + author="F. {Abinader (Ed.)} and S. {Gundavelli (Ed.)} and K. Leung and S. Krishnan and D. Premec", + title="{Bulk Binding Update Support for Proxy Mobile IPv6}", + howpublished="RFC 6602 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6602", + pages="1--23", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6602.txt", + key="RFC 6602", + abstract={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]}, + keywords="Proxy Mobile IPv6, PMIPv6, bulk registrations, MN group ID", + doi="10.17487/RFC6602", + } + +@misc{rfc6603, + author="J. {Korhonen (Ed.)} and T. Savolainen and S. Krishnan and O. Troan", + title="{Prefix Exclude Option for DHCPv6-based Prefix Delegation}", + howpublished="RFC 6603 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6603", + pages="1--10", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6603.txt", + key="RFC 6603", + abstract={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]}, + keywords="OPTION\_PD\_EXCLUDE", + doi="10.17487/RFC6603", + } + +@misc{rfc6604, + author="D. {Eastlake 3rd}", + title="{xNAME RCODE and Status Bits Clarification}", + howpublished="RFC 6604 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6604", + pages="1--5", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6604.txt", + key="RFC 6604", + abstract={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]}, + keywords="DNS, DNSSEC, CNAME, DNAME, Domain Name, response code, canonical name", + doi="10.17487/RFC6604", + } + +@misc{rfc6605, + author="P. Hoffman and W.C.A. Wijngaards", + title="{Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC}", + howpublished="RFC 6605 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6605", + pages="1--8", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6605.txt", + key="RFC 6605", + abstract={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]}, + keywords="dnskey algorithm, ds hash algo, crypto, DNS key, DNSKEY algorithm, DS, digest hash cryptography, SHA-384, ECDSAP256SHA256, ECDSAP384SHA384", + doi="10.17487/RFC6605", + } + +@misc{rfc6606, + author="E. Kim and D. Kaspar and C. Gomez and C. Bormann", + title="{Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing}", + howpublished="RFC 6606 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6606", + pages="1--32", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6606.txt", + key="RFC 6606", + abstract={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. 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 specific ation; it is published for informational purposes.}, + keywords="WSN, Sensor Network, Wireless Sensor Network, WSN for Wireless Sensor Network, L3 Mesh for Layer 3 Mesh Network, Routing Protocol, Subnet Routing, ieee 802.15.4, LLN, Low Power, radio 802.15.4, powerline, ISA100.11a, RFC 4944", + doi="10.17487/RFC6606", + } + +@misc{rfc6607, + author="K. Kinnear and R. Johnson and M. Stapp", + title="{Virtual Subnet Selection Options for DHCPv4 and DHCPv6}", + howpublished="RFC 6607 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6607", + pages="1--26", + year=2012, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6607.txt", + key="RFC 6607", + doi="10.17487/RFC6607", + } + +@misc{rfc6608, + author="J. Dong and M. Chen and A. Suryanarayana", + title="{Subcodes for BGP Finite State Machine Error}", + howpublished="RFC 6608 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6608", + pages="1--5", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6608.txt", + key="RFC 6608", + abstract={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]}, + keywords="", + doi="10.17487/RFC6608", + } + +@misc{rfc6609, + author="C. Daboo and A. Stone", + title="{Sieve Email Filtering: Include Extension}", + howpublished="RFC 6609 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6609", + pages="1--14", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6609.txt", + key="RFC 6609", + abstract={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]}, + keywords="", + doi="10.17487/RFC6609", + } + +@misc{rfc6610, + author="H. Jang and A. Yegin and K. Chowdhury and J. Choi and T. Lemon", + title="{DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)}", + howpublished="RFC 6610 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6610", + pages="1--16", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6610.txt", + key="RFC 6610", + abstract={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]}, + keywords="", + doi="10.17487/RFC6610", + } + +@misc{rfc6611, + author="K. {Chowdhury (Ed.)} and A. Yegin", + title="{Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario}", + howpublished="RFC 6611 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6611", + pages="1--12", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6611.txt", + key="RFC 6611", + abstract={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]}, + keywords="", + doi="10.17487/RFC6611", + } + +@misc{rfc6612, + author="G. {Giaretta (Ed.)}", + title="{Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues}", + howpublished="RFC 6612 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6612", + pages="1--18", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6612.txt", + key="RFC 6612", + abstract={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.}, + doi="10.17487/RFC6612", + } + +@misc{rfc6613, + author="A. DeKok", + title="{RADIUS over TCP}", + howpublished="RFC 6613 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6613", + pages="1--16", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7930", +url="https://www.rfc-editor.org/rfc/rfc6613.txt", + key="RFC 6613", + abstract={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.}, + keywords="Remote Authentication Dial-In User Server, Transmission Control Protocol, RADIUS/TCP", + doi="10.17487/RFC6613", + } + +@misc{rfc6614, + author="S. Winter and M. McCauley and S. Venaas and K. Wierenga", + title="{Transport Layer Security (TLS) Encryption for RADIUS}", + howpublished="RFC 6614 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6614", + pages="1--22", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6614.txt", + key="RFC 6614", + abstract={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]}, + keywords="RADIUS, AAA, Security, Reliability, Remote Authentication Dial-In User Server", + doi="10.17487/RFC6614", + } + +@misc{rfc6615, + author="T. {Dietz (Ed.)} and A. Kobayashi and B. Claise and G. Muenz", + title="{Definitions of Managed Objects for IP Flow Information Export}", + howpublished="RFC 6615 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6615", + pages="1--65", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6615.txt", + key="RFC 6615", + abstract={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]}, + keywords="IPFIX, MIB, Filtering, Sampling, Selection", + doi="10.17487/RFC6615", + } + +@misc{rfc6616, + author="E. Lear and H. Tschofenig and H. Mauldin and S. Josefsson", + title="{A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID}", + howpublished="RFC 6616 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6616", + pages="1--18", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6616.txt", + key="RFC 6616", + abstract={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]}, + keywords="web single sign-on", + doi="10.17487/RFC6616", + } + +@misc{rfc6617, + author="D. Harkins", + title="{Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)}", + howpublished="RFC 6617 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6617", + pages="1--24", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6617.txt", + key="RFC 6617", + abstract={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.}, + keywords="Authenticated Key Exchange, Dictionary Attack", + doi="10.17487/RFC6617", + } + +@misc{rfc6618, + author="J. {Korhonen (Ed.)} and B. Patil and H. Tschofenig and D. Kroeselberg", + title="{Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent}", + howpublished="RFC 6618 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6618", + pages="1--38", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6618.txt", + key="RFC 6618", + abstract={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.}, + keywords="Mobile IPv6, Security", + doi="10.17487/RFC6618", + } + +@misc{rfc6619, + author="J. Arkko and L. Eggert and M. Townsley", + title="{Scalable Operation of Address Translators with Per-Interface Bindings}", + howpublished="RFC 6619 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6619", + pages="1--9", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6619.txt", + key="RFC 6619", + abstract={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]}, + keywords="NAT, IPv4, IPv6", + doi="10.17487/RFC6619", + } + +@misc{rfc6620, + author="E. Nordmark and M. Bagnulo and E. Levy-Abegnoli", + title="{FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses}", + howpublished="RFC 6620 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6620", + pages="1--35", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6620.txt", + key="RFC 6620", + abstract={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]}, + keywords="ingress filtering, BCP38", + doi="10.17487/RFC6620", + } + +@misc{rfc6621, + author="J. {Macker (Ed.)}", + title="{Simplified Multicast Forwarding}", + howpublished="RFC 6621 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6621", + pages="1--55", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6621.txt", + key="RFC 6621", + abstract={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 p rovided 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.}, + keywords="routing, flooding, optimized flooding, CDS, connected dominating set, duplicate packet detection, hash-based packet detection, MPR, MPR-CDS, E-CDS, edge mobility, mobile ad hoc, mesh network", + doi="10.17487/RFC6621", + } + +@misc{rfc6622, + author="U. Herberg and T. Clausen", + title="{Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)}", + howpublished="RFC 6622 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6622", + pages="1--21", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7182", +url="https://www.rfc-editor.org/rfc/rfc6622.txt", + key="RFC 6622", + abstract={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]}, + keywords="packetbb, NHDP, OLSRv2, security, integrity, routing", + doi="10.17487/RFC6622", + } + +@misc{rfc6623, + author="E. Burger", + title="{IANA Registry for MEDIACTRL Interactive Voice Response Control Package}", + howpublished="RFC 6623 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6623", + pages="1--6", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6623.txt", + key="RFC 6623", + abstract={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]}, + keywords="", + doi="10.17487/RFC6623", + } + +@misc{rfc6624, + author="K. Kompella and B. Kothari and R. Cherukuri", + title="{Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling}", + howpublished="RFC 6624 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6624", + pages="1--26", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6624.txt", + key="RFC 6624", + abstract={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.}, + keywords="BGP, L2VPN, discovery, signaling, pseudowire", + doi="10.17487/RFC6624", + } + +@misc{rfc6625, + author="E. {Rosen (Ed.)} and Y. {Rekhter (Ed.)} and W. Hendrickx and R. Qiu", + title="{Wildcards in Multicast VPN Auto-Discovery Routes}", + howpublished="RFC 6625 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6625", + pages="1--17", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7582, 7900", +url="https://www.rfc-editor.org/rfc/rfc6625.txt", + key="RFC 6625", + abstract={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 e ven to all customer flows. [STANDARDS-TRACK]}, + keywords="mvpn", + doi="10.17487/RFC6625", + } + +@misc{rfc6626, + author="G. Tsirtsis and V. Park and V. Narayanan and K. Leung", + title="{Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4)}", + howpublished="RFC 6626 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6626", + pages="1--5", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6626.txt", + key="RFC 6626", + abstract={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]}, + keywords="mobile router", + doi="10.17487/RFC6626", + } + +@misc{rfc6627, + author="G. Karagiannis and K. Chan and T. Moncaster and M. Menth and P. Eardley and B. Briscoe", + title="{Overview of Pre-Congestion Notification Encoding}", + howpublished="RFC 6627 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6627", + pages="1--20", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6627.txt", + key="RFC 6627", + abstract={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. 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.}, + doi="10.17487/RFC6627", + } + +@misc{rfc6628, + author="S. Shin and K. Kobara", + title="{Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2}", + howpublished="RFC 6628 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6628", + pages="1--20", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6628.txt", + key="RFC 6628", + abstract={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.}, + keywords="PAKE, augmented PAKE, off-line dictionary attacks, resistance to server compromise", + doi="10.17487/RFC6628", + } + +@misc{rfc6629, + author="J. Abley and M. Bagnulo and A. Garcia-Martinez", + title="{Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)}", + howpublished="RFC 6629 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6629", + pages="1--28", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6629.txt", + key="RFC 6629", + abstract={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.}, + keywords="Cryptographically Generated Address, CGA, Hash-Based Address, HBA, Fault tolerance", + doi="10.17487/RFC6629", + } + +@misc{rfc6630, + author="Z. Cao and H. Deng and Q. Wu and G. {Zorn (Ed.)}", + title="{EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)}", + howpublished="RFC 6630 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6630", + pages="1--20", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6630.txt", + key="RFC 6630", + abstract={The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. 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. 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. This document specifies the extensions necessary to enable AAK support in ERP. [STANDARDS-TRACK]}, + keywords="ERP, AAK, EAP, Early-authentication", + doi="10.17487/RFC6630", + } + +@misc{rfc6631, + author="D. Kuegler and Y. Sheffer", + title="{Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)}", + howpublished="RFC 6631 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6631", + pages="1--26", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6631.txt", + key="RFC 6631", + abstract={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.}, + keywords="pace, password authenticated connection establishment", + doi="10.17487/RFC6631", + } + +@misc{rfc6632, + author="M. {Ersue (Ed.)} and B. Claise", + title="{An Overview of the IETF Network Management Standards}", + howpublished="RFC 6632 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6632", + pages="1--85", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6632.txt", + key="RFC 6632", + abstract={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 specifica tion; it is published for informational purposes.}, + keywords="network management, data model, monitoring, configuration, alarm, notification", + doi="10.17487/RFC6632", + } + +@misc{rfc6633, + author="F. Gont", + title="{Deprecation of ICMP Source Quench Messages}", + howpublished="RFC 6633 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6633", + pages="1--8", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6633.txt", + key="RFC 6633", + abstract={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]}, + keywords="congestion control, icmp attacks, tcp, tcp security, udp, dccp, sctp", + doi="10.17487/RFC6633", + } + +@misc{rfc6635, + author="O. {Kolkman (Ed.)} and J. {Halpern (Ed.)} and IAB", + title="{RFC Editor Model (Version 2)}", + howpublished="RFC 6635 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6635", + pages="1--21", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6635.txt", + key="RFC 6635", + abstract={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.}, + keywords="RFC Series Editor, Independenet Series Editor, RSE, ISE, RSOC, RFC Series Oversight Committee", + doi="10.17487/RFC6635", + } + +@misc{rfc6636, + author="H. Asaeda and H. Liu and Q. Wu", + title="{Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks}", + howpublished="RFC 6636 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6636", + pages="1--12", + year=2012, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6636.txt", + key="RFC 6636", + abstract={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.}, + keywords="Mobility, PMIPv6", + doi="10.17487/RFC6636", + } + +@misc{rfc6637, + author="A. Jivsov", + title="{Elliptic Curve Cryptography (ECC) in OpenPGP}", + howpublished="RFC 6637 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6637", + pages="1--15", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6637.txt", + key="RFC 6637", + abstract={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]}, + doi="10.17487/RFC6637", + } + +@misc{rfc6638, + author="C. Daboo and B. Desruisseaux", + title="{Scheduling Extensions to CalDAV}", + howpublished="RFC 6638 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6638", + pages="1--78", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7953", +url="https://www.rfc-editor.org/rfc/rfc6638.txt", + key="RFC 6638", + abstract={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]}, + keywords="calsify, calsched, calsch, calendar, calendaring, webcal, ical, icalendar, ischedule, itip, imip, text/calendar, http", + doi="10.17487/RFC6638", + } + +@misc{rfc6639, + author="D. {King (Ed.)} and M. {Venkatesan (Ed.)}", + title="{Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview}", + howpublished="RFC 6639 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6639", + pages="1--29", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6639.txt", + key="RFC 6639", + abstract={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. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. 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.}, + doi="10.17487/RFC6639", + } + +@misc{rfc6640, + author="W. George", + title="{IETF Meeting Attendees' Frequently Asked (Travel) Questions}", + howpublished="RFC 6640 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6640", + pages="1--13", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6640.txt", + key="RFC 6640", + abstract={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.}, + keywords="Meetings", + doi="10.17487/RFC6640", + } + +@misc{rfc6641, + author="C. Everhart and W. Adamson and J. Zhang", + title="{Using DNS SRV to Specify a Global File Namespace with NFS Version 4}", + howpublished="RFC 6641 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6641", + pages="1--11", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6641.txt", + key="RFC 6641", + abstract={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]}, + keywords="domainroot, domain root file system", + doi="10.17487/RFC6641", + } + +@misc{rfc6642, + author="Q. {Wu (Ed.)} and F. Xia and R. Even", + title="{RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report}", + howpublished="RFC 6642 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6642", + pages="1--13", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6642.txt", + key="RFC 6642", + abstract={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]}, + keywords="Feedback Suppression, NACK, Retransmission", + doi="10.17487/RFC6642", + } + +@misc{rfc6643, + author="J. Schoenwaelder", + title="{Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules}", + howpublished="RFC 6643 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6643", + pages="1--36", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6643.txt", + key="RFC 6643", + abstract={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]}, + keywords="SMIv2, YANG, data modeling", + doi="10.17487/RFC6643", + } + +@misc{rfc6644, + author="D. Evans and R. Droms and S. Jiang", + title="{Rebind Capability in DHCPv6 Reconfigure Messages}", + howpublished="RFC 6644 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6644", + pages="1--10", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6644.txt", + key="RFC 6644", + abstract={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]}, + keywords="internet protocol, parameters, addresses", + doi="10.17487/RFC6644", + } + +@misc{rfc6645, + author="J. Novak", + title="{IP Flow Information Accounting and Export Benchmarking Methodology}", + howpublished="RFC 6645 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6645", + pages="1--39", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6645.txt", + key="RFC 6645", + abstract={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.}, + keywords="Performance, Flow monitoring, IPFIX, Netflow", + doi="10.17487/RFC6645", + } + +@misc{rfc6646, + author="H. Song and N. Zong and Y. Yang and R. Alimi", + title="{DECoupled Application Data Enroute (DECADE) Problem Statement}", + howpublished="RFC 6646 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6646", + pages="1--12", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6646.txt", + key="RFC 6646", + abstract={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.}, + keywords="In-network storage, P2P", + doi="10.17487/RFC6646", + } + +@misc{rfc6647, + author="M. Kucherawy and D. Crocker", + title="{Email Greylisting: An Applicability Statement for SMTP}", + howpublished="RFC 6647 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6647", + pages="1--17", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6647.txt", + key="RFC 6647", + abstract={This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK]}, + keywords="Email, Greylisting, Spam", + doi="10.17487/RFC6647", + } + +@misc{rfc6648, + author="P. Saint-Andre and D. Crocker and M. Nottingham", + title="{Deprecating the ``X-'' Prefix and Similar Constructs in Application Protocols}", + howpublished="RFC 6648 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6648", + pages="1--13", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6648.txt", + key="RFC 6648", + abstract={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.}, + keywords="", + doi="10.17487/RFC6648", + } + +@misc{rfc6649, + author="L. Hornquist Astrand and T. Yu", + title="{Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos}", + howpublished="RFC 6649 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6649", + pages="1--7", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6649.txt", + key="RFC 6649", + abstract={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.}, + keywords="", + doi="10.17487/RFC6649", + } + +@misc{rfc6650, + author="J. Falk and M. {Kucherawy (Ed.)}", + title="{Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)}", + howpublished="RFC 6650 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6650", + pages="1--15", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6650.txt", + key="RFC 6650", + abstract={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]}, + keywords="marf, spam reporting", + doi="10.17487/RFC6650", + } + +@misc{rfc6651, + author="M. Kucherawy", + title="{Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting}", + howpublished="RFC 6651 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6651", + pages="1--18", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6651.txt", + key="RFC 6651", + abstract={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]}, + keywords="authentication, fraud, phishing, spoofing", + doi="10.17487/RFC6651", + } + +@misc{rfc6652, + author="S. Kitterman", + title="{Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format}", + howpublished="RFC 6652 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6652", + pages="1--8", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6652.txt", + key="RFC 6652", + abstract={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. This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]}, + keywords="fraud, phishing, spoofing", + doi="10.17487/RFC6652", + } + +@misc{rfc6653, + author="B. Sarikaya and F. Xia and T. Lemon", + title="{DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks}", + howpublished="RFC 6653 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6653", + pages="1--13", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6653.txt", + key="RFC 6653", + abstract={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.}, + doi="10.17487/RFC6653", + } + +@misc{rfc6654, + author="T. Tsou and C. Zhou and T. Taylor and Q. Chen", + title="{Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)}", + howpublished="RFC 6654 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6654", + pages="1--8", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6654.txt", + key="RFC 6654", + abstract={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 purpos es.}, + keywords="IPv6 transition", + doi="10.17487/RFC6654", + } + +@misc{rfc6655, + author="D. McGrew and D. Bailey", + title="{AES-CCM Cipher Suites for Transport Layer Security (TLS)}", + howpublished="RFC 6655 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6655", + pages="1--8", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6655.txt", + key="RFC 6655", + abstract={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]}, + keywords="Authentication, Encryption, Advanced Encryption Standard (AES)", + doi="10.17487/RFC6655", + } + +@misc{rfc6656, + author="R. Johnson and K. Kinnear and M. Stapp", + title="{Description of Cisco Systems' Subnet Allocation Option for DHCPv4}", + howpublished="RFC 6656 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6656", + pages="1--24", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6656.txt", + key="RFC 6656", + abstract={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.}, + doi="10.17487/RFC6656", + } + +@misc{rfc6657, + author="A. Melnikov and J. Reschke", + title="{Update to MIME regarding ``charset'' Parameter Handling in Textual Media Types}", + howpublished="RFC 6657 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6657", + pages="1--6", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6657.txt", + key="RFC 6657", + abstract={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]}, + keywords="MIME, charset, text", + doi="10.17487/RFC6657", + } + +@misc{rfc6658, + author="S. {Bryant (Ed.)} and L. Martini and G. Swallow and A. Malis", + title="{Packet Pseudowire Encapsulation over an MPLS PSN}", + howpublished="RFC 6658 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6658", + pages="1--15", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6658.txt", + key="RFC 6658", + abstract={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]}, + keywords="", + doi="10.17487/RFC6658", + } + +@misc{rfc6659, + author="A. Begen", + title="{Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method}", + howpublished="RFC 6659 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6659", + pages="1--12", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6659.txt", + key="RFC 6659", + abstract={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 sce narios. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + keywords="IPTV, FEC, retransmission", + doi="10.17487/RFC6659", + } + +@misc{rfc6660, + author="B. Briscoe and T. Moncaster and M. Menth", + title="{Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)}", + howpublished="RFC 6660 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6660", + pages="1--24", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6660.txt", + key="RFC 6660", + abstract={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. 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), thres hold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]}, + keywords="Quality of Service, QoS, Congestion Control, Congestion Notification, Tunnelling, Encapsulation \& Decapsulation, Differentiated Services, Integrated Services, Signalling, Protocol, Flow Admission Control, Flow Termination", + doi="10.17487/RFC6660", + } + +@misc{rfc6661, + author="A. Charny and F. Huang and G. Karagiannis and M. Menth and T. {Taylor (Ed.)}", + title="{Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation}", + howpublished="RFC 6661 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6661", + pages="1--33", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6661.txt", + key="RFC 6661", + abstract={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.}, + keywords="PCN, controlled load, CL, boundary node behavior", + doi="10.17487/RFC6661", + } + +@misc{rfc6662, + author="A. Charny and J. Zhang and G. Karagiannis and M. Menth and T. {Taylor (Ed.)}", + title="{Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation}", + howpublished="RFC 6662 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6662", + pages="1--31", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6662.txt", + key="RFC 6662", + abstract={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.}, + keywords="PCN, single marking, SM, edge node behavior", + doi="10.17487/RFC6662", + } + +@misc{rfc6663, + author="G. Karagiannis and T. Taylor and K. Chan and M. Menth and P. Eardley", + title="{Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain}", + howpublished="RFC 6663 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6663", + pages="1--7", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6663.txt", + key="RFC 6663", + abstract={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.}, + doi="10.17487/RFC6663", + } + +@misc{rfc6664, + author="J. Schaad", + title="{S/MIME Capabilities for Public Key Definitions}", + howpublished="RFC 6664 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6664", + pages="1--19", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6664.txt", + key="RFC 6664", + abstract={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.}, + keywords="OCSP, CMS", + doi="10.17487/RFC6664", + } + +@misc{rfc6665, + author="A.B. Roach", + title="{SIP-Specific Event Notification}", + howpublished="RFC 6665 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6665", + pages="1--53", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7621", +url="https://www.rfc-editor.org/rfc/rfc6665.txt", + key="RFC 6665", + abstract={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. 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. 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]}, + keywords="SUBSCRIBE, NOTIFY, state", + doi="10.17487/RFC6665", + } + +@misc{rfc6666, + author="N. Hilliard and D. Freedman", + title="{A Discard Prefix for IPv6}", + howpublished="RFC 6666 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6666", + pages="1--6", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6666.txt", + key="RFC 6666", + abstract={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.}, + keywords="RTBH, black hole", + doi="10.17487/RFC6666", + } + +@misc{rfc6667, + author="K. Raza and S. Boutros and C. Pignataro", + title="{LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements}", + howpublished="RFC 6667 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6667", + pages="1--8", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6667.txt", + key="RFC 6667", + abstract={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]}, + keywords="", + doi="10.17487/RFC6667", + } + +@misc{rfc6668, + author="D. Bider and M. Baushke", + title="{SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol}", + howpublished="RFC 6668 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6668", + pages="1--5", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6668.txt", + key="RFC 6668", + abstract={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]}, + keywords="", + doi="10.17487/RFC6668", + } + +@misc{rfc6669, + author="N. Sprecher and L. Fang", + title="{An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks}", + howpublished="RFC 6669 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6669", + pages="1--21", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6669.txt", + key="RFC 6669", + abstract={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.}, + doi="10.17487/RFC6669", + } + +@misc{rfc6670, + author="N. Sprecher and KY. Hong", + title="{The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)}", + howpublished="RFC 6670 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6670", + pages="1--33", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6670.txt", + key="RFC 6670", + abstract={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. 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. 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 protoco l 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.}, + doi="10.17487/RFC6670", + } + +@misc{rfc6671, + author="M. Betts", + title="{Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)}", + howpublished="RFC 6671 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6671", + pages="1--5", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6671.txt", + key="RFC 6671", + abstract={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.}, + doi="10.17487/RFC6671", + } + +@misc{rfc6672, + author="S. Rose and W. Wijngaards", + title="{DNAME Redirection in the DNS}", + howpublished="RFC 6672 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6672", + pages="1--22", + year=2012, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6672.txt", + key="RFC 6672", + abstract={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]}, + keywords="", + doi="10.17487/RFC6672", + } + +@misc{rfc6673, + author="A. Morton", + title="{Round-Trip Packet Loss Metrics}", + howpublished="RFC 6673 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6673", + pages="1--14", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6673.txt", + key="RFC 6673", + abstract={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. This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]}, + keywords="IP, IPPM", + doi="10.17487/RFC6673", + } + +@misc{rfc6674, + author="F. Brockners and S. Gundavelli and S. Speicher and D. Ward", + title="{Gateway-Initiated Dual-Stack Lite Deployment}", + howpublished="RFC 6674 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6674", + pages="1--15", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6674.txt", + key="RFC 6674", + abstract={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]}, + keywords="GI-DS-Lite, Gateway Initiated Dual-Stack Lite, Dual-Stack Lite, IPv6 Transitioning, IPv6 Migration", + doi="10.17487/RFC6674", + } + +@misc{rfc6675, + author="E. Blanton and M. Allman and L. Wang and I. Jarvinen and M. Kojo and Y. Nishida", + title="{A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP}", + howpublished="RFC 6675 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6675", + pages="1--15", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6675.txt", + key="RFC 6675", + abstract={This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 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]}, + keywords="transmission control protocol, retransmission, congestion control", + doi="10.17487/RFC6675", + } + +@misc{rfc6676, + author="S. Venaas and R. Parekh and G. Van de Velde and T. Chown and M. Eubanks", + title="{Multicast Addresses for Documentation}", + howpublished="RFC 6676 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6676", + pages="1--7", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6676.txt", + key="RFC 6676", + abstract={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.}, + doi="10.17487/RFC6676", + } + +@misc{rfc6677, + author="S. {Hartman (Ed.)} and T. Clancy and K. Hoeper", + title="{Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods}", + howpublished="RFC 6677 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6677", + pages="1--31", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6677.txt", + key="RFC 6677", + abstract={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]}, + keywords="", + doi="10.17487/RFC6677", + } + +@misc{rfc6678, + author="K. Hoeper and S. Hanna and H. Zhou and J. {Salowey (Ed.)}", + title="{Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method}", + howpublished="RFC 6678 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6678", + pages="1--23", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6678.txt", + key="RFC 6678", + abstract={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.}, + doi="10.17487/RFC6678", + } + +@misc{rfc6679, + author="M. Westerlund and I. Johansson and C. Perkins and P. O'Hanlon and K. Carlberg", + title="{Explicit Congestion Notification (ECN) for RTP over UDP}", + howpublished="RFC 6679 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6679", + pages="1--58", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8311", +url="https://www.rfc-editor.org/rfc/rfc6679.txt", + key="RFC 6679", + abstract={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]}, + keywords="ECN, RTP, UDP, Congestion Control, VoIP, IPTV, Packet Loss", + doi="10.17487/RFC6679", + } + +@misc{rfc6680, + author="N. Williams and L. Johansson and S. Hartman and S. Josefsson", + title="{Generic Security Service Application Programming Interface (GSS-API) Naming Extensions}", + howpublished="RFC 6680 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6680", + pages="1--18", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6680.txt", + key="RFC 6680", + abstract={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.}, + keywords="", + doi="10.17487/RFC6680", + } + +@misc{rfc6681, + author="M. Watson and T. Stockhammer and M. Luby", + title="{Raptor Forward Error Correction (FEC) Schemes for FECFRAME}", + howpublished="RFC 6681 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6681", + pages="1--22", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6681.txt", + key="RFC 6681", + abstract={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]}, + keywords="", + doi="10.17487/RFC6681", + } + +@misc{rfc6682, + author="M. Watson and T. Stockhammer and M. Luby", + title="{RTP Payload Format for Raptor Forward Error Correction (FEC)}", + howpublished="RFC 6682 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6682", + pages="1--18", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6682.txt", + key="RFC 6682", + abstract={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]}, + keywords="", + doi="10.17487/RFC6682", + } + +@misc{rfc6683, + author="A. Begen and T. Stockhammer", + title="{Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection}", + howpublished="RFC 6683 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6683", + pages="1--11", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6683.txt", + key="RFC 6683", + abstract={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.}, + keywords="DVB, FEC, AL-FEC, IPTV, parity codes, Raptor codes", + doi="10.17487/RFC6683", + } + +@misc{rfc6684, + author="B. Trammell", + title="{Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)}", + howpublished="RFC 6684 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6684", + pages="1--12", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6684.txt", + key="RFC 6684", + abstract={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.}, + keywords="mile, incident handling", + doi="10.17487/RFC6684", + } + +@misc{rfc6685, + author="B. Trammell", + title="{Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry}", + howpublished="RFC 6685 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6685", + pages="1--3", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7970", +url="https://www.rfc-editor.org/rfc/rfc6685.txt", + key="RFC 6685", + abstract={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]}, + keywords="mile, xml schema", + doi="10.17487/RFC6685", + } + +@misc{rfc6686, + author="M. Kucherawy", + title="{Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments}", + howpublished="RFC 6686 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6686", + pages="1--12", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6686.txt", + key="RFC 6686", + abstract={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. 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. 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 S tandards Track specification; it is published for informational purposes.}, + keywords="SPF, Sender ID, authentication, authorization, email", + doi="10.17487/RFC6686", + } + +@misc{rfc6687, + author="J. {Tripathi (Ed.)} and J. de {Oliveira (Ed.)} and JP. {Vasseur (Ed.)}", + title="{Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)}", + howpublished="RFC 6687 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6687", + pages="1--26", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6687.txt", + key="RFC 6687", + abstract={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.}, + keywords="ROLL", + doi="10.17487/RFC6687", + } + +@misc{rfc6688, + author="D. {Black (Ed.)} and J. Glasgow and S. Faibish", + title="{Parallel NFS (pNFS) Block Disk Protection}", + howpublished="RFC 6688 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6688", + pages="1--6", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6688.txt", + key="RFC 6688", + abstract={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]}, + keywords="NFS, NFSv4, pNFS, SAN, GPT", + doi="10.17487/RFC6688", + } + +@misc{rfc6689, + author="L. Berger", + title="{Usage of the RSVP ASSOCIATION Object}", + howpublished="RFC 6689 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6689", + pages="1--11", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6689.txt", + key="RFC 6689", + abstract={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.}, + keywords="Resource Reservation Protocol", + doi="10.17487/RFC6689", + } + +@misc{rfc6690, + author="Z. Shelby", + title="{Constrained RESTful Environments (CoRE) Link Format}", + howpublished="RFC 6690 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6690", + pages="1--22", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6690.txt", + key="RFC 6690", + abstract={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]}, + keywords="CoRE, Link Format, HTTP Link Header Format, Resource Discovery", + doi="10.17487/RFC6690", + } + +@misc{rfc6691, + author="D. Borman", + title="{TCP Options and Maximum Segment Size (MSS)}", + howpublished="RFC 6691 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6691", + pages="1--9", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6691.txt", + key="RFC 6691", + abstract={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.}, + doi="10.17487/RFC6691", + } + +@misc{rfc6692, + author="R. Clayton and M. Kucherawy", + title="{Source Ports in Abuse Reporting Format (ARF) Reports}", + howpublished="RFC 6692 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6692", + pages="1--5", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6692.txt", + key="RFC 6692", + abstract={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. This document updates RFC 6591. [STANDARDS-TRACK]}, + keywords="ARF, ports, reporting, feedback", + doi="10.17487/RFC6692", + } + +@misc{rfc6693, + author="A. Lindgren and A. Doria and E. Davies and S. Grasic", + title="{Probabilistic Routing Protocol for Intermittently Connected Networks}", + howpublished="RFC 6693 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6693", + pages="1--113", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6693.txt", + key="RFC 6693", + abstract={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 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 dela y and disruption tolerant). The document presents an architectural overview followed by the protocol specification. This document defines an Experimental Protocol for the Internet community.}, + keywords="DTN, Routing, PRoPHET", + doi="10.17487/RFC6693", + } + +@misc{rfc6694, + author="S. {Moonesamy (Ed.)}", + title="{The ``about'' URI Scheme}", + howpublished="RFC 6694 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6694", + pages="1--7", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6694.txt", + key="RFC 6694", + abstract={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.}, + doi="10.17487/RFC6694", + } + +@misc{rfc6695, + author="R. Asati", + title="{Methods to Convey Forward Error Correction (FEC) Framework Configuration Information}", + howpublished="RFC 6695 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6695", + pages="1--15", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6695.txt", + key="RFC 6695", + abstract={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). This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + doi="10.17487/RFC6695", + } + +@misc{rfc6696, + author="Z. Cao and B. He and Y. Shi and Q. {Wu (Ed.)} and G. {Zorn (Ed.)}", + title="{EAP Extensions for the EAP Re-authentication Protocol (ERP)}", + howpublished="RFC 6696 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6696", + pages="1--47", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6696.txt", + key="RFC 6696", + abstract={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]}, + keywords="EAP keying, EMSK, inter-authenticator roaming", + doi="10.17487/RFC6696", + } + +@misc{rfc6697, + author="G. {Zorn (Ed.)} and Q. Wu and T. Taylor and Y. Nir and K. Hoeper and S. Decugis", + title="{Handover Keying (HOKEY) Architecture Design}", + howpublished="RFC 6697 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6697", + pages="1--20", + year=2012, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6697.txt", + key="RFC 6697", + abstract={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. 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 archite cture 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.}, + keywords="Handover Keying Architecture, Re-authentication, Early authentication", + doi="10.17487/RFC6697", + } + +@misc{rfc6698, + author="P. Hoffman and J. Schlyter", + title="{The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA}", + howpublished="RFC 6698 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6698", + pages="1--37", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7218, 7671", +url="https://www.rfc-editor.org/rfc/rfc6698.txt", + key="RFC 6698", + abstract={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]}, + keywords="DNSSEC, certificates, public keys, PKI", + doi="10.17487/RFC6698", + } + +@misc{rfc6701, + author="A. Farrel and P. Resnick", + title="{Sanctions Available for Application to Violators of IETF IPR Policy}", + howpublished="RFC 6701 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6701", + pages="1--12", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6701.txt", + key="RFC 6701", + abstract={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. 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. 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.}, + doi="10.17487/RFC6701", + } + +@misc{rfc6702, + author="T. Polk and P. Saint-Andre", + title="{Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules}", + howpublished="RFC 6702 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6702", + pages="1--16", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6702.txt", + key="RFC 6702", + abstract={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.}, + doi="10.17487/RFC6702", + } + +@misc{rfc6703, + author="A. Morton and G. Ramachandran and G. Maguluri", + title="{Reporting IP Network Performance Metrics: Different Points of View}", + howpublished="RFC 6703 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6703", + pages="1--27", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6703.txt", + key="RFC 6703", + abstract={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.}, + keywords="Loss, Delay, Delay Variation, Capacity, TCP", + doi="10.17487/RFC6703", + } + +@misc{rfc6704, + author="D. Miles and W. Dec and J. Bristow and R. Maglione", + title="{Forcerenew Nonce Authentication}", + howpublished="RFC 6704 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6704", + pages="1--12", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6704.txt", + key="RFC 6704", + abstract={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]}, + keywords="DHCP", + doi="10.17487/RFC6704", + } + +@misc{rfc6705, + author="S. Krishnan and R. Koodli and P. Loureiro and Q. Wu and A. Dutta", + title="{Localized Routing for Proxy Mobile IPv6}", + howpublished="RFC 6705 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6705", + pages="1--20", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6705.txt", + key="RFC 6705", + abstract={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]}, + keywords="PMIPv6", + doi="10.17487/RFC6705", + } + +@misc{rfc6706, + author="F. {Templin (Ed.)}", + title="{Asymmetric Extended Route Optimization (AERO)}", + howpublished="RFC 6706 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6706", + pages="1--33", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6706.txt", + key="RFC 6706", + abstract={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 Asymmetr ic Extended Route Optimization (AERO) capability that addresses the issues. This document defines an Experimental Protocol for the Internet community.}, + keywords="route, optimize, optimization, redirect, redirection, protocol, routing, link, multi-access, IPv6", + doi="10.17487/RFC6706", + } + +@misc{rfc6707, + author="B. Niven-Jenkins and F. Le Faucheur and N. Bitar", + title="{Content Distribution Network Interconnection (CDNI) Problem Statement}", + howpublished="RFC 6707 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6707", + pages="1--32", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6707.txt", + key="RFC 6707", + abstract={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. The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Inter connection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + keywords="Delivery, CDN", + doi="10.17487/RFC6707", + } + +@misc{rfc6708, + author="S. {Kiesel (Ed.)} and S. Previdi and M. Stiemerling and R. Woundy and Y. Yang", + title="{Application-Layer Traffic Optimization (ALTO) Requirements}", + howpublished="RFC 6708 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6708", + pages="1--20", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6708.txt", + key="RFC 6708", + abstract={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. 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.}, + doi="10.17487/RFC6708", + } + +@misc{rfc6709, + author="B. Carpenter and B. {Aboba (Ed.)} and S. Cheshire", + title="{Design Considerations for Protocol Extensions}", + howpublished="RFC 6709 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6709", + pages="1--42", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6709.txt", + key="RFC 6709", + abstract={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.}, + doi="10.17487/RFC6709", + } + +@misc{rfc6710, + author="A. Melnikov and K. Carlberg", + title="{Simple Mail Transfer Protocol Extension for Message Transfer Priorities}", + howpublished="RFC 6710 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6710", + pages="1--28", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6710.txt", + key="RFC 6710", + abstract={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]}, + keywords="SMTP, priority, MMHS", + doi="10.17487/RFC6710", + } + +@misc{rfc6711, + author="L. Johansson", + title="{An IANA Registry for Level of Assurance (LoA) Profiles}", + howpublished="RFC 6711 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6711", + pages="1--7", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6711.txt", + key="RFC 6711", + abstract={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.}, + keywords="Identity, Assurance", + doi="10.17487/RFC6711", + } + +@misc{rfc6712, + author="T. Kause and M. Peylo", + title="{Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)}", + howpublished="RFC 6712 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6712", + pages="1--10", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6712.txt", + key="RFC 6712", + abstract={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]}, + keywords="CMPtrans", + doi="10.17487/RFC6712", + } + +@misc{rfc6713, + author="J. Levine", + title="{The 'application/zlib' and 'application/gzip' Media Types}", + howpublished="RFC 6713 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6713", + pages="1--4", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6713.txt", + key="RFC 6713", + abstract={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.}, + keywords="compress, deflate, stream compression", + doi="10.17487/RFC6713", + } + +@misc{rfc6714, + author="C. Holmberg and S. Blau and E. Burger", + title="{Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)}", + howpublished="RFC 6714 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6714", + pages="1--22", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6714.txt", + key="RFC 6714", + abstract={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]}, + keywords="Middlebox, IBCF, SBC", + doi="10.17487/RFC6714", + } + +@misc{rfc6715, + author="D. Cauchie and B. Leiba and K. Li", + title="{vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group}", + howpublished="RFC 6715 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6715", + pages="1--11", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6715.txt", + key="RFC 6715", + abstract={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]}, + keywords="expertise, hobby, interest", + doi="10.17487/RFC6715", + } + +@misc{rfc6716, + author="JM. Valin and K. Vos and T. Terriberry", + title="{Definition of the Opus Audio Codec}", + howpublished="RFC 6716 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6716", + pages="1--326", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8251", +url="https://www.rfc-editor.org/rfc/rfc6716.txt", + key="RFC 6716", + abstract={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]}, + keywords="voice, music, lossy compression, VOIP", + doi="10.17487/RFC6716", + } + +@misc{rfc6717, + author="H. Hotz and R. Allbery", + title="{kx509 Kerberized Certificate Issuance Protocol in Use in 2012}", + howpublished="RFC 6717 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6717", + pages="1--13", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6717.txt", + key="RFC 6717", + abstract={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. 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.}, + keywords="Kerberos, X.509, kx509, KCA, kca-service, kca\_service", + doi="10.17487/RFC6717", + } + +@misc{rfc6718, + author="P. Muley and M. Aissaoui and M. Bocci", + title="{Pseudowire Redundancy}", + howpublished="RFC 6718 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6718", + pages="1--18", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6718.txt", + key="RFC 6718", + abstract={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.}, + keywords="Active, standby, protection, dual-homing, vpls, vpws", + doi="10.17487/RFC6718", + } + +@misc{rfc6719, + author="O. Gnawali and P. Levis", + title="{The Minimum Rank with Hysteresis Objective Function}", + howpublished="RFC 6719 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6719", + pages="1--13", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6719.txt", + key="RFC 6719", + abstract={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]}, + keywords="Routing Protocol for Low Power and Lossy Networks, RPL, Low Power and Lossy Networks, LLN", + doi="10.17487/RFC6719", + } + +@misc{rfc6720, + author="C. Pignataro and R. Asati", + title="{The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)}", + howpublished="RFC 6720 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6720", + pages="1--8", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7552", +url="https://www.rfc-editor.org/rfc/rfc6720.txt", + key="RFC 6720", + abstract={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). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. [STANDARDS-TRACK]}, + keywords="GTSM, LDP", + doi="10.17487/RFC6720", + } + +@misc{rfc6721, + author="J. Snell", + title="{The Atom ``deleted-entry'' Element}", + howpublished="RFC 6721 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6721", + pages="1--10", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6721.txt", + key="RFC 6721", + abstract={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]}, + keywords="Atom Feed, Entry Documents", + doi="10.17487/RFC6721", + } + +@misc{rfc6722, + author="P. {Hoffman (Ed.)}", + title="{Publishing the ``Tao of the IETF'' as a Web Page}", + howpublished="RFC 6722 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6722", + pages="1--3", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6722.txt", + key="RFC 6722", + abstract={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.}, + doi="10.17487/RFC6722", + } + +@misc{rfc6723, + author="L. {Jin (Ed.)} and R. {Key (Ed.)} and S. Delord and T. Nadeau and S. Boutros", + title="{Update of the Pseudowire Control-Word Negotiation Mechanism}", + howpublished="RFC 6723 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6723", + pages="1--9", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8077", +url="https://www.rfc-editor.org/rfc/rfc6723.txt", + key="RFC 6723", + abstract={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]}, + keywords="control word, control word negotiation, control word renegotiation, control word negotiation mechanism, control word renegotiation mechanism", + doi="10.17487/RFC6723", + } + +@misc{rfc6724, + author="D. {Thaler (Ed.)} and R. Draves and A. Matsumoto and T. Chown", + title="{Default Address Selection for Internet Protocol Version 6 (IPv6)}", + howpublished="RFC 6724 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6724", + pages="1--32", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6724.txt", + key="RFC 6724", + abstract={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. 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]}, + keywords="source, destination, sort, sorting", + doi="10.17487/RFC6724", + } + +@misc{rfc6725, + author="S. Rose", + title="{DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates}", + howpublished="RFC 6725 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6725", + pages="1--5", + year=2012, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6725.txt", + key="RFC 6725", + abstract={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]}, + keywords="", + doi="10.17487/RFC6725", + } + +@misc{rfc6726, + author="T. Paila and R. Walsh and M. Luby and V. Roca and R. Lehtonen", + title="{FLUTE - File Delivery over Unidirectional Transport}", + howpublished="RFC 6726 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6726", + pages="1--46", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6726.txt", + key="RFC 6726", + abstract={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]}, + keywords="Multicast", + doi="10.17487/RFC6726", + } + +@misc{rfc6727, + author="T. {Dietz (Ed.)} and B. Claise and J. Quittek", + title="{Definitions of Managed Objects for Packet Sampling}", + howpublished="RFC 6727 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6727", + pages="1--28", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6727.txt", + key="RFC 6727", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes 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]}, + keywords="PSAMP, IPFIX, MIB, Sampling, Filtering, Selection", + doi="10.17487/RFC6727", + } + +@misc{rfc6728, + author="G. Muenz and B. Claise and P. Aitken", + title="{Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols}", + howpublished="RFC 6728 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6728", + pages="1--129", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6728.txt", + key="RFC 6728", + abstract={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]}, + keywords="", + doi="10.17487/RFC6728", + } + +@misc{rfc6729, + author="D. Crocker and M. Kucherawy", + title="{Indicating Email Handling States in Trace Fields}", + howpublished="RFC 6729 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6729", + pages="1--12", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6729.txt", + key="RFC 6729", + abstract={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]}, + keywords="Quarantine, Moderation", + doi="10.17487/RFC6729", + } + +@misc{rfc6730, + author="S. Krishnan and J. Halpern", + title="{Requirements for IETF Nominations Committee Tools}", + howpublished="RFC 6730 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6730", + pages="1--10", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6730.txt", + key="RFC 6730", + abstract={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.}, + doi="10.17487/RFC6730", + } + +@misc{rfc6731, + author="T. Savolainen and J. Kato and T. Lemon", + title="{Improved Recursive DNS Server Selection for Multi-Interfaced Nodes}", + howpublished="RFC 6731 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6731", + pages="1--29", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6731.txt", + key="RFC 6731", + abstract={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]}, + keywords="DNS, RDNSS, interface, FQDN, selection", + doi="10.17487/RFC6731", + } + +@misc{rfc6732, + author="V. {Kuarsingh (Ed.)} and Y. Lee and O. Vautrin", + title="{6to4 Provider Managed Tunnels}", + howpublished="RFC 6732 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6732", + pages="1--12", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7526", +url="https://www.rfc-editor.org/rfc/rfc6732.txt", + key="RFC 6732", + abstract={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.}, + keywords="6to4-PMT", + doi="10.17487/RFC6732", + } + +@misc{rfc6733, + author="V. {Fajardo (Ed.)} and J. Arkko and J. Loughney and G. {Zorn (Ed.)}", + title="{Diameter Base Protocol}", + howpublished="RFC 6733 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6733", + pages="1--152", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7075", +url="https://www.rfc-editor.org/rfc/rfc6733.txt", + key="RFC 6733", + abstract={The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility 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]}, + keywords="Diameter, AAA", + doi="10.17487/RFC6733", + } + +@misc{rfc6734, + author="G. Zorn and Q. Wu and V. Cakulev", + title="{Diameter Attribute-Value Pairs for Cryptographic Key Transport}", + howpublished="RFC 6734 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6734", + pages="1--7", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6734.txt", + key="RFC 6734", + abstract={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]}, + keywords="AAA,ERP,MSK", + doi="10.17487/RFC6734", + } + +@misc{rfc6735, + author="K. {Carlberg (Ed.)} and T. Taylor", + title="{Diameter Priority Attribute-Value Pairs}", + howpublished="RFC 6735 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6735", + pages="1--10", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6735.txt", + key="RFC 6735", + abstract={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]}, + keywords="AVP", + doi="10.17487/RFC6735", + } + +@misc{rfc6736, + author="F. Brockners and S. Bhandari and V. Singh and V. Fajardo", + title="{Diameter Network Address and Port Translation Control Application}", + howpublished="RFC 6736 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6736", + pages="1--58", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6736.txt", + key="RFC 6736", + abstract={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 an d 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]}, + keywords="NAT control, NAT44, NAT66, CGN, BNG", + doi="10.17487/RFC6736", + } + +@misc{rfc6737, + author="K. Jiao and G. Zorn", + title="{The Diameter Capabilities Update Application}", + howpublished="RFC 6737 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6737", + pages="1--6", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6737.txt", + key="RFC 6737", + abstract={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]}, + doi="10.17487/RFC6737", + } + +@misc{rfc6738, + author="V. Cakulev and A. Lior and S. Mizikovsky", + title="{Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers}", + howpublished="RFC 6738 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6738", + pages="1--17", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6738.txt", + key="RFC 6738", + abstract={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). 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]}, + keywords="Internet Key Exchange Protocol version 2", + doi="10.17487/RFC6738", + } + +@misc{rfc6739, + author="H. Schulzrinne and H. Tschofenig", + title="{Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol}", + howpublished="RFC 6739 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6739", + pages="1--25", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6739.txt", + key="RFC 6739", + abstract={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. The <mapping> 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. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> 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.}, + keywords="Location", + doi="10.17487/RFC6739", + } + +@misc{rfc6740, + author="RJ Atkinson and SN Bhatti", + title="{Identifier-Locator Network Protocol (ILNP) Architectural Description}", + howpublished="RFC 6740 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6740", + pages="1--53", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6740.txt", + key="RFC 6740", + abstract={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.}, + doi="10.17487/RFC6740", + } + +@misc{rfc6741, + author="RJ Atkinson and SN Bhatti", + title="{Identifier-Locator Network Protocol (ILNP) Engineering Considerations}", + howpublished="RFC 6741 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6741", + pages="1--38", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6741.txt", + key="RFC 6741", + abstract={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.}, + doi="10.17487/RFC6741", + } + +@misc{rfc6742, + author="RJ Atkinson and SN Bhatti and S. Rose", + title="{DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)}", + howpublished="RFC 6742 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6742", + pages="1--20", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6742.txt", + key="RFC 6742", + abstract={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.}, + doi="10.17487/RFC6742", + } + +@misc{rfc6743, + author="RJ Atkinson and SN Bhatti", + title="{ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)}", + howpublished="RFC 6743 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6743", + pages="1--12", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6743.txt", + key="RFC 6743", + abstract={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.}, + doi="10.17487/RFC6743", + } + +@misc{rfc6744, + author="RJ Atkinson and SN Bhatti", + title="{IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)}", + howpublished="RFC 6744 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6744", + pages="1--14", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6744.txt", + key="RFC 6744", + abstract={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.}, + doi="10.17487/RFC6744", + } + +@misc{rfc6745, + author="RJ Atkinson and SN Bhatti", + title="{ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)}", + howpublished="RFC 6745 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6745", + pages="1--12", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6745.txt", + key="RFC 6745", + abstract={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.}, + doi="10.17487/RFC6745", + } + +@misc{rfc6746, + author="RJ Atkinson and SN Bhatti", + title="{IPv4 Options for the Identifier-Locator Network Protocol (ILNP)}", + howpublished="RFC 6746 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6746", + pages="1--11", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6746.txt", + key="RFC 6746", + abstract={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.}, + doi="10.17487/RFC6746", + } + +@misc{rfc6747, + author="RJ Atkinson and SN Bhatti", + title="{Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)}", + howpublished="RFC 6747 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6747", + pages="1--12", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6747.txt", + key="RFC 6747", + abstract={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.}, + doi="10.17487/RFC6747", + } + +@misc{rfc6748, + author="RJ Atkinson and SN Bhatti", + title="{Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)}", + howpublished="RFC 6748 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6748", + pages="1--37", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6748.txt", + key="RFC 6748", + abstract={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.}, + doi="10.17487/RFC6748", + } + +@misc{rfc6749, + author="D. {Hardt (Ed.)}", + title="{The OAuth 2.0 Authorization Framework}", + howpublished="RFC 6749 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6749", + pages="1--76", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8252", +url="https://www.rfc-editor.org/rfc/rfc6749.txt", + key="RFC 6749", + abstract={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]}, + keywords="Client, Resource Owner, Authorization Server, Resource Server, Token Endpoint, AuthorizationÂ Endpoint, Authorization Request, Authorization Grant, Protected Resource, Access Token, RefreshÂ Token, Authorization Code, Implicit Grant, Client Identifier, Access Token Scope, Delegation", + doi="10.17487/RFC6749", + } + +@misc{rfc6750, + author="M. Jones and D. Hardt", + title="{The OAuth 2.0 Authorization Framework: Bearer Token Usage}", + howpublished="RFC 6750 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6750", + pages="1--18", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6750.txt", + key="RFC 6750", + abstract={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]}, + keywords="Client, Resource Owner, Authorization Server, Resource Server,Â Token Endpoint, Authorization Endpoint, Authorization Request,Â Authorization Grant, Protected Resource, Access Token, RefreshÂ Token, Authorization Code, Implicit Grant, Client Identifier,Â Access Token Scope, Bearer Authorization Header, Bearer AccessÂ Token Type", + doi="10.17487/RFC6750", + } + +@misc{rfc6751, + author="R. {Despres (Ed.)} and B. Carpenter and D. Wing and S. Jiang", + title="{Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)}", + howpublished="RFC 6751 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6751", + pages="1--33", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6751.txt", + key="RFC 6751", + abstract={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 do cument defines an Experimental Protocol for the Internet community.}, + keywords="Coexistence, Transition, Interworking, Tunneling, Encapsulation, Mapping, map-and-encap, Global Addressing", + doi="10.17487/RFC6751", + } + +@misc{rfc6752, + author="A. Kirkham", + title="{Issues with Private IP Addressing in the Internet}", + howpublished="RFC 6752 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6752", + pages="1--14", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6752.txt", + key="RFC 6752", + abstract={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.}, + doi="10.17487/RFC6752", + } + +@misc{rfc6753, + author="J. Winterbottom and H. Tschofenig and H. Schulzrinne and M. Thomson", + title="{A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)}", + howpublished="RFC 6753 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6753", + pages="1--25", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6753.txt", + key="RFC 6753", + abstract={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]}, + keywords="HELD, Dereference, lbyr, HTTP, Location, GEOPRIV", + doi="10.17487/RFC6753", + } + +@misc{rfc6754, + author="Y. Cai and L. Wei and H. Ou and V. Arya and S. Jethwani", + title="{Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect}", + howpublished="RFC 6754 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6754", + pages="1--12", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6754.txt", + key="RFC 6754", + abstract={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]}, + keywords="", + doi="10.17487/RFC6754", + } + +@misc{rfc6755, + author="B. Campbell and H. Tschofenig", + title="{An IETF URN Sub-Namespace for OAuth}", + howpublished="RFC 6755 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6755", + pages="1--5", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6755.txt", + key="RFC 6755", + abstract={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.}, + keywords="OAuth, URN, sub-namespace, urn:ietf:params:oauth", + doi="10.17487/RFC6755", + } + +@misc{rfc6756, + author="S. {Trowbridge (Ed.)} and E. {Lear (Ed.)} and G. {Fishman (Ed.)} and S. {Bradner (Ed.)}", + title="{Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines}", + howpublished="RFC 6756 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6756", + pages="1--16", + year=2012, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6756.txt", + key="RFC 6756", + abstract={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). Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.}, + doi="10.17487/RFC6756", + } + +@misc{rfc6757, + author="S. {Gundavelli (Ed.)} and J. {Korhonen (Ed.)} and M. Grayson and K. Leung and R. Pazhyannur", + title="{Access Network Identifier (ANI) Option for Proxy Mobile IPv6}", + howpublished="RFC 6757 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6757", + pages="1--19", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7563", +url="https://www.rfc-editor.org/rfc/rfc6757.txt", + key="RFC 6757", + abstract={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]}, + keywords="ANI, ANI option, Access Network Identifier option, PMIPv6 ANI option", + doi="10.17487/RFC6757", + } + +@misc{rfc6758, + author="A. Melnikov and K. Carlberg", + title="{Tunneling of SMTP Message Transfer Priorities}", + howpublished="RFC 6758 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6758", + pages="1--11", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6758.txt", + key="RFC 6758", + abstract={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.}, + keywords="Priority, MMHS", + doi="10.17487/RFC6758", + } + +@misc{rfc6759, + author="B. Claise and P. Aitken and N. Ben-Dvora", + title="{Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)}", + howpublished="RFC 6759 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6759", + pages="1--43", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6759.txt", + key="RFC 6759", + abstract={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.}, + doi="10.17487/RFC6759", + } + +@misc{rfc6760, + author="S. Cheshire and M. Krochmal", + title="{Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)}", + howpublished="RFC 6760 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6760", + pages="1--16", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6760.txt", + key="RFC 6760", + abstract={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.}, + doi="10.17487/RFC6760", + } + +@misc{rfc6761, + author="S. Cheshire and M. Krochmal", + title="{Special-Use Domain Names}", + howpublished="RFC 6761 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6761", + pages="1--13", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6761.txt", + key="RFC 6761", + abstract={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.}, + doi="10.17487/RFC6761", + } + +@misc{rfc6762, + author="S. Cheshire and M. Krochmal", + title="{Multicast DNS}", + howpublished="RFC 6762 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6762", + pages="1--70", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6762.txt", + key="RFC 6762", + abstract={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. 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. 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.}, + doi="10.17487/RFC6762", + } + +@misc{rfc6763, + author="S. Cheshire and M. Krochmal", + title="{DNS-Based Service Discovery}", + howpublished="RFC 6763 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6763", + pages="1--49", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6763.txt", + key="RFC 6763", + abstract={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.}, + doi="10.17487/RFC6763", + } + +@misc{rfc6764, + author="C. Daboo", + title="{Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)}", + howpublished="RFC 6764 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6764", + pages="1--14", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6764.txt", + key="RFC 6764", + abstract={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.}, + keywords="SRV, iCalendar", + doi="10.17487/RFC6764", + } + +@misc{rfc6765, + author="E. Beili and M. Morgenstern", + title="{xDSL Multi-Pair Bonding (G.Bond) MIB}", + howpublished="RFC 6765 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6765", + pages="1--73", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6765.txt", + key="RFC 6765", + abstract={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.}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, xDSL bonding, aggregation, G.998, G.998.1, G.998.2, G.998.3, TDIM, IMA, EFM", + doi="10.17487/RFC6765", + } + +@misc{rfc6766, + author="E. Beili", + title="{xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB}", + howpublished="RFC 6766 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6766", + pages="1--55", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6766.txt", + key="RFC 6766", + abstract={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.}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, xDSL bonding, aggregation, G.998.3", + doi="10.17487/RFC6766", + } + +@misc{rfc6767, + author="E. Beili and M. Morgenstern", + title="{Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB}", + howpublished="RFC 6767 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6767", + pages="1--53", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6767.txt", + key="RFC 6767", + abstract={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.}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, xDSL bonding, Ethernet bonding, aggregation, 802.3ah, G.998.2", + doi="10.17487/RFC6767", + } + +@misc{rfc6768, + author="E. Beili", + title="{ATM-Based xDSL Bonded Interfaces MIB}", + howpublished="RFC 6768 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6768", + pages="1--34", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6768.txt", + key="RFC 6768", + abstract={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.}, + keywords="Network Management, Simple Network Management Protocol, SNMP, Management Information Base, bonding, xDSL bonding, aggregation, G.Bond, G.Bond/ATM, G.998.1, IMA, IMA+", + doi="10.17487/RFC6768", + } + +@misc{rfc6769, + author="R. Raszuk and J. Heitz and A. Lo and L. Zhang and X. Xu", + title="{Simple Virtual Aggregation (S-VA)}", + howpublished="RFC 6769 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6769", + pages="1--8", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6769.txt", + key="RFC 6769", + abstract={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). 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. 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 informati onal purposes.}, + keywords="BGP, aggregation", + doi="10.17487/RFC6769", + } + +@misc{rfc6770, + author="G. {Bertrand (Ed.)} and E. Stephan and T. Burbridge and P. Eardley and K. Ma and G. Watson", + title="{Use Cases for Content Delivery Network Interconnection}", + howpublished="RFC 6770 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6770", + pages="1--16", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6770.txt", + key="RFC 6770", + abstract={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.}, + keywords="CDN, CDNI", + doi="10.17487/RFC6770", + } + +@misc{rfc6771, + author="L. Eggert and G. Camarillo", + title="{Considerations for Having a Successful ``Bar BOF'' Side Meeting}", + howpublished="RFC 6771 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6771", + pages="1--10", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6771.txt", + key="RFC 6771", + abstract={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. 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. 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 i n 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.}, + doi="10.17487/RFC6771", + } + +@misc{rfc6772, + author="H. {Schulzrinne (Ed.)} and H. {Tschofenig (Ed.)} and J. Cuellar and J. Polk and J. Morris and M. Thomson", + title="{Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information}", + howpublished="RFC 6772 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6772", + pages="1--44", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6772.txt", + key="RFC 6772", + abstract={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. 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]}, + keywords="Authorization Policy, Location Privacy", + doi="10.17487/RFC6772", + } + +@misc{rfc6773, + author="T. Phelan and G. Fairhurst and C. Perkins", + title="{DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal}", + howpublished="RFC 6773 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6773", + pages="1--20", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6773.txt", + key="RFC 6773", + abstract={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]}, + keywords="DCCP, NAPT, NAT, UDP", + doi="10.17487/RFC6773", + } + +@misc{rfc6774, + author="R. {Raszuk (Ed.)} and R. Fernando and K. Patel and D. McPherson and K. Kumaki", + title="{Distribution of Diverse BGP Paths}", + howpublished="RFC 6774 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6774", + pages="1--22", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6774.txt", + key="RFC 6774", + abstract={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. 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. 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.}, + doi="10.17487/RFC6774", + } + +@misc{rfc6775, + author="Z. {Shelby (Ed.)} and S. Chakrabarti and E. Nordmark and C. Bormann", + title="{Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}", + howpublished="RFC 6775 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6775", + pages="1--55", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6775.txt", + key="RFC 6775", + abstract={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]}, + keywords="", + doi="10.17487/RFC6775", + } + +@misc{rfc6776, + author="A. Clark and Q. Wu", + title="{Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block}", + howpublished="RFC 6776 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6776", + pages="1--9", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6776.txt", + key="RFC 6776", + abstract={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]}, + keywords="RTP Control Protocol", + doi="10.17487/RFC6776", + } + +@misc{rfc6777, + author="W. {Sun (Ed.)} and G. {Zhang (Ed.)} and J. Gao and G. Xie and R. Papneja", + title="{Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks}", + howpublished="RFC 6777 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6777", + pages="1--29", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6777.txt", + key="RFC 6777", + abstract={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 signa ling process. [STANDARDS-TRACK]}, + keywords="Provisioning performance, Performance measurement, UNI, Bandwidth on Demand, performance evaluation, Measurement methodologies", + doi="10.17487/RFC6777", + } + +@misc{rfc6778, + author="R. Sparks", + title="{Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching}", + howpublished="RFC 6778 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6778", + pages="1--8", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6778.txt", + key="RFC 6778", + abstract={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.}, + keywords="tool", + doi="10.17487/RFC6778", + } + +@misc{rfc6779, + author="U. Herberg and R. Cole and I. Chakeres", + title="{Definition of Managed Objects for the Neighborhood Discovery Protocol}", + howpublished="RFC 6779 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6779", + pages="1--67", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7939", +url="https://www.rfc-editor.org/rfc/rfc6779.txt", + key="RFC 6779", + abstract={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]}, + keywords="Network Management, Management Information base, MIB, SMIv2, Routing, Neighbor Discovery, MANET", + doi="10.17487/RFC6779", + } + +@misc{rfc6780, + author="L. Berger and F. Le Faucheur and A. Narayanan", + title="{RSVP ASSOCIATION Object Extensions}", + howpublished="RFC 6780 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6780", + pages="1--17", + year=2012, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6780.txt", + key="RFC 6780", + abstract={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]}, + keywords="", + doi="10.17487/RFC6780", + } + +@misc{rfc6781, + author="O. Kolkman and W. Mekking and R. Gieben", + title="{DNSSEC Operational Practices, Version 2}", + howpublished="RFC 6781 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6781", + pages="1--71", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6781.txt", + key="RFC 6781", + abstract={This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. 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. 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.}, + keywords="DNSSEC, operational, key rollover", + doi="10.17487/RFC6781", + } + +@misc{rfc6782, + author="V. {Kuarsingh (Ed.)} and L. Howard", + title="{Wireline Incremental IPv6}", + howpublished="RFC 6782 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6782", + pages="1--29", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6782.txt", + key="RFC 6782", + abstract={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.}, + keywords="transition, IPv6 transition, operator", + doi="10.17487/RFC6782", + } + +@misc{rfc6783, + author="J. Levine and R. Gellens", + title="{Mailing Lists and Non-ASCII Addresses}", + howpublished="RFC 6783 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6783", + pages="1--9", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6783.txt", + key="RFC 6783", + abstract={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).}, + keywords="Mail, internationalization, mailing lists", + doi="10.17487/RFC6783", + } + +@misc{rfc6784, + author="S. Sakane and M. Ishiyama", + title="{Kerberos Options for DHCPv6}", + howpublished="RFC 6784 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6784", + pages="1--12", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6784.txt", + key="RFC 6784", + abstract={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]}, + keywords="security, dhcpv6", + doi="10.17487/RFC6784", + } + +@misc{rfc6785, + author="B. Leiba", + title="{Support for Internet Message Access Protocol (IMAP) Events in Sieve}", + howpublished="RFC 6785 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6785", + pages="1--20", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6785.txt", + key="RFC 6785", + abstract={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]}, + keywords="email, filtering", + doi="10.17487/RFC6785", + } + +@misc{rfc6786, + author="A. Yegin and R. Cragie", + title="{Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs}", + howpublished="RFC 6786 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6786", + pages="1--11", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6786.txt", + key="RFC 6786", + abstract={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]}, + keywords="", + doi="10.17487/RFC6786", + } + +@misc{rfc6787, + author="D. Burnett and S. Shanmugham", + title="{Media Resource Control Protocol Version 2 (MRCPv2)}", + howpublished="RFC 6787 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6787", + pages="1--224", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6787.txt", + key="RFC 6787", + abstract={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]}, + keywords="mrcp, speechsc, asr, tts, speech services, speech recognition, speech synthesis, nlsml, speaker authentication, speaker verification, speaker identification", + doi="10.17487/RFC6787", + } + +@misc{rfc6788, + author="S. Krishnan and A. Kavanagh and B. Varga and S. Ooghe and E. Nordmark", + title="{The Line-Identification Option}", + howpublished="RFC 6788 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6788", + pages="1--17", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6788.txt", + key="RFC 6788", + abstract={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]}, + keywords="", + doi="10.17487/RFC6788", + } + +@misc{rfc6789, + author="B. {Briscoe (Ed.)} and R. {Woundy (Ed.)} and A. {Cooper (Ed.)}", + title="{Congestion Exposure (ConEx) Concepts and Use Cases}", + howpublished="RFC 6789 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6789", + pages="1--17", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6789.txt", + key="RFC 6789", + abstract={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.}, + keywords="Congestion Signaling, Traffic Management", + doi="10.17487/RFC6789", + } + +@misc{rfc6790, + author="K. Kompella and J. Drake and S. Amante and W. Henderickx and L. Yong", + title="{The Use of Entropy Labels in MPLS Forwarding}", + howpublished="RFC 6790 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6790", + pages="1--25", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7274, 7447, 8012", +url="https://www.rfc-editor.org/rfc/rfc6790.txt", + key="RFC 6790", + abstract={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]}, + keywords="entropy, hash, ecmp, load balancing", + doi="10.17487/RFC6790", + } + +@misc{rfc6791, + author="X. Li and C. Bao and D. Wing and R. Vaithianathan and G. Huston", + title="{Stateless Source Address Mapping for ICMPv6 Packets}", + howpublished="RFC 6791 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6791", + pages="1--6", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6791.txt", + key="RFC 6791", + abstract={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]}, + keywords="IP/ICMP Translation Algorithm, IPv4-translatable IPv6 addresses, ICMPv6, traceroute", + doi="10.17487/RFC6791", + } + +@misc{rfc6792, + author="Q. {Wu (Ed.)} and G. Hunt and P. Arden", + title="{Guidelines for Use of the RTP Monitoring Framework}", + howpublished="RFC 6792 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6792", + pages="1--17", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6792.txt", + key="RFC 6792", + abstract={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.}, + keywords="Real Time Control Protocol", + doi="10.17487/RFC6792", + } + +@misc{rfc6793, + author="Q. Vohra and E. Chen", + title="{BGP Support for Four-Octet Autonomous System (AS) Number Space}", + howpublished="RFC 6793 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6793", + pages="1--12", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6793.txt", + key="RFC 6793", + abstract={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]}, + keywords="autonomous system, border gateway protocol", + doi="10.17487/RFC6793", + } + +@misc{rfc6794, + author="V. Hilt and G. Camarillo and J. Rosenberg", + title="{A Framework for Session Initiation Protocol (SIP) Session Policies}", + howpublished="RFC 6794 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6794", + pages="1--36", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6794.txt", + key="RFC 6794", + abstract={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]}, + keywords="", + doi="10.17487/RFC6794", + } + +@misc{rfc6795, + author="V. Hilt and G. Camarillo", + title="{A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies}", + howpublished="RFC 6795 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6795", + pages="1--18", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6795.txt", + key="RFC 6795", + abstract={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]}, + keywords="", + doi="10.17487/RFC6795", + } + +@misc{rfc6796, + author="V. Hilt and G. Camarillo and J. Rosenberg and D. Worley", + title="{A User Agent Profile Data Set for Media Policy}", + howpublished="RFC 6796 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6796", + pages="1--43", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6796.txt", + key="RFC 6796", + abstract={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]}, + keywords="SIP, Session Policy, Data Set", + doi="10.17487/RFC6796", + } + +@misc{rfc6797, + author="J. Hodges and C. Jackson and A. Barth", + title="{HTTP Strict Transport Security (HSTS)}", + howpublished="RFC 6797 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6797", + pages="1--46", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6797.txt", + key="RFC 6797", + abstract={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]}, + keywords="HTTPS, TLS, SSL, ForceHTTPS, man-in-the-middle, MITM, certificate error, certificate verification, security policy, secure transport, IDNA-Canonicalization", + doi="10.17487/RFC6797", + } + +@misc{rfc6798, + author="A. Clark and Q. Wu", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting}", + howpublished="RFC 6798 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6798", + pages="1--13", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6798.txt", + key="RFC 6798", + abstract={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]}, + keywords="", + doi="10.17487/RFC6798", + } + +@misc{rfc6801, + author="U. Kozat and A. Begen", + title="{Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework}", + howpublished="RFC 6801 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6801", + pages="1--11", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6801.txt", + key="RFC 6801", + abstract={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.}, + doi="10.17487/RFC6801", + } + +@misc{rfc6802, + author="S. Baillargeon and C. Flinta and A. Johnsson", + title="{Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets}", + howpublished="RFC 6802 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6802", + pages="1--15", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6802.txt", + key="RFC 6802", + abstract={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.}, + keywords="available capacity, rate, train, interval, padding, buffer, test session", + doi="10.17487/RFC6802", + } + +@misc{rfc6803, + author="G. Hudson", + title="{Camellia Encryption for Kerberos 5}", + howpublished="RFC 6803 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6803", + pages="1--13", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6803.txt", + key="RFC 6803", + abstract={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.}, + keywords="Camellia, Kerberos", + doi="10.17487/RFC6803", + } + +@misc{rfc6804, + author="B. Manning", + title="{DISCOVER: Supporting Multicast DNS Queries}", + howpublished="RFC 6804 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="6804", + pages="1--9", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6804.txt", + key="RFC 6804", + abstract={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.}, + doi="10.17487/RFC6804", + } + +@misc{rfc6805, + author="D. {King (Ed.)} and A. {Farrel (Ed.)}", + title="{The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS}", + howpublished="RFC 6805 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6805", + pages="1--33", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6805.txt", + key="RFC 6805", + abstract={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. 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. 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 arc hitecture 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.}, + doi="10.17487/RFC6805", + } + +@misc{rfc6806, + author="S. {Hartman (Ed.)} and K. Raeburn and L. Zhu", + title="{Kerberos Principal Name Canonicalization and Cross-Realm Referrals}", + howpublished="RFC 6806 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6806", + pages="1--19", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6806.txt", + key="RFC 6806", + abstract={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]}, + keywords="authentication, security protocols, identity", + doi="10.17487/RFC6806", + } + +@misc{rfc6807, + author="D. Farinacci and G. Shepherd and S. Venaas and Y. Cai", + title="{Population Count Extensions to Protocol Independent Multicast (PIM)}", + howpublished="RFC 6807 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6807", + pages="1--15", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6807.txt", + key="RFC 6807", + abstract={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.}, + doi="10.17487/RFC6807", + } + +@misc{rfc6808, + author="L. Ciavattone and R. Geib and A. Morton and M. Wieser", + title="{Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track}", + howpublished="RFC 6808 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6808", + pages="1--29", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6808.txt", + key="RFC 6808", + abstract={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.}, + keywords="One-way Delay, IP Performance Metrics, IPPM", + doi="10.17487/RFC6808", + } + +@misc{rfc6809, + author="C. Holmberg and I. Sedlacek and H. Kaplan", + title="{Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6809 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6809", + pages="1--19", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6809.txt", + key="RFC 6809", + abstract={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. 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. 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]}, + keywords="proxy, feature, feature tag, feature-capability indicator, Feature-Caps, capability", + doi="10.17487/RFC6809", + } + +@misc{rfc6810, + author="R. Bush and R. Austein", + title="{The Resource Public Key Infrastructure (RPKI) to Router Protocol}", + howpublished="RFC 6810 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6810", + pages="1--27", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8210", +url="https://www.rfc-editor.org/rfc/rfc6810.txt", + key="RFC 6810", + abstract={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]}, + keywords="", + doi="10.17487/RFC6810", + } + +@misc{rfc6811, + author="P. Mohapatra and J. Scudder and D. Ward and R. Bush and R. Austein", + title="{BGP Prefix Origin Validation}", + howpublished="RFC 6811 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6811", + pages="1--10", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8481", +url="https://www.rfc-editor.org/rfc/rfc6811.txt", + key="RFC 6811", + abstract={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]}, + keywords="SIDR, security", + doi="10.17487/RFC6811", + } + +@misc{rfc6812, + author="M. Chiba and A. Clemm and S. Medley and J. Salowey and S. Thombare and E. Yedavalli", + title="{Cisco Service-Level Assurance Protocol}", + howpublished="RFC 6812 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6812", + pages="1--27", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6812.txt", + key="RFC 6812", + abstract={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.}, + keywords="Cisco's SLA Protocol", + doi="10.17487/RFC6812", + } + +@misc{rfc6813, + author="J. Salowey and S. Hanna", + title="{The Network Endpoint Assessment (NEA) Asokan Attack Analysis}", + howpublished="RFC 6813 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6813", + pages="1--8", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6813.txt", + key="RFC 6813", + abstract={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.}, + keywords="Man-in-the-Middle, MITM, Security, Endpoint, Posture, Protocol, Forwarding, TNC, Channel, Binding, Cryptographic, Countermeasure", + doi="10.17487/RFC6813", + } + +@misc{rfc6814, + author="C. Pignataro and F. Gont", + title="{Formally Deprecating Some IPv4 Options}", + howpublished="RFC 6814 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6814", + pages="1--6", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6814.txt", + key="RFC 6814", + abstract={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]}, + keywords="", + doi="10.17487/RFC6814", + } + +@misc{rfc6815, + author="S. Bradner and K. Dubray and J. McQuaid and A. Morton", + title="{Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful}", + howpublished="RFC 6815 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6815", + pages="1--11", + year=2012, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6815.txt", + key="RFC 6815", + abstract={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.}, + keywords="testing, performance", + doi="10.17487/RFC6815", + } + +@misc{rfc6816, + author="V. Roca and M. Cunche and J. Lacan", + title="{Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME}", + howpublished="RFC 6816 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6816", + pages="1--24", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6816.txt", + key="RFC 6816", + abstract={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.}, + keywords="Forward Error Correction, LDPC-Staircase", + doi="10.17487/RFC6816", + } + +@misc{rfc6817, + author="S. Shalunov and G. Hazel and J. Iyengar and M. Kuehlewind", + title="{Low Extra Delay Background Transport (LEDBAT)}", + howpublished="RFC 6817 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6817", + pages="1--25", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6817.txt", + key="RFC 6817", + abstract={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.}, + keywords="Congestion control, delay-based, scavenger, P2P", + doi="10.17487/RFC6817", + } + +@misc{rfc6818, + author="P. Yee", + title="{Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}", + howpublished="RFC 6818 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6818", + pages="1--8", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6818.txt", + key="RFC 6818", + abstract={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]}, + keywords="", + doi="10.17487/RFC6818", + } + +@misc{rfc6819, + author="T. {Lodderstedt (Ed.)} and M. McGloin and P. Hunt", + title="{OAuth 2.0 Threat Model and Security Considerations}", + howpublished="RFC 6819 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6819", + pages="1--71", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6819.txt", + key="RFC 6819", + abstract={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.}, + keywords="authorization, authentication, token, counter-measures, HTTP, REST", + doi="10.17487/RFC6819", + } + +@misc{rfc6820, + author="T. Narten and M. Karir and I. Foo", + title="{Address Resolution Problems in Large Data Center Networks}", + howpublished="RFC 6820 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6820", + pages="1--17", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6820.txt", + key="RFC 6820", + abstract={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).}, + keywords="ARMD, data center, ARP, ND, Neighbor Discovery", + doi="10.17487/RFC6820", + } + +@misc{rfc6821, + author="E. Marocco and A. Fusco and I. Rimac and V. Gurbani", + title="{Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality}", + howpublished="RFC 6821 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6821", + pages="1--16", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6821.txt", + key="RFC 6821", + abstract={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. This document is a product of the IRTF P2PRG (Peer-to-Peer Research Group).}, + keywords="cross-domain traffic, bandwidth, transit traffic, peer-to-peer caching, peer-to-peer swarm", + doi="10.17487/RFC6821", + } + +@misc{rfc6822, + author="S. {Previdi (Ed.)} and L. Ginsberg and M. Shand and A. Roy and D. Ward", + title="{IS-IS Multi-Instance}", + howpublished="RFC 6822 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6822", + pages="1--14", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8202", +url="https://www.rfc-editor.org/rfc/rfc6822.txt", + key="RFC 6822", + abstract={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. 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.}, + keywords="intermediate system to intermediate system", + doi="10.17487/RFC6822", + } + +@misc{rfc6823, + author="L. Ginsberg and S. Previdi and M. Shand", + title="{Advertising Generic Information in IS-IS}", + howpublished="RFC 6823 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6823", + pages="1--11", + year=2012, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6823.txt", + key="RFC 6823", + abstract={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.}, + keywords="intermediate system to intermediate system", + doi="10.17487/RFC6823", + } + +@misc{rfc6824, + author="A. Ford and C. Raiciu and M. Handley and O. Bonaventure", + title="{TCP Extensions for Multipath Operation with Multiple Addresses}", + howpublished="RFC 6824 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6824", + pages="1--64", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6824.txt", + key="RFC 6824", + abstract={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. 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.}, + doi="10.17487/RFC6824", + } + +@misc{rfc6825, + author="M. Miyazawa and T. Otani and K. Kumaki and T. Nadeau", + title="{Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS}", + howpublished="RFC 6825 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6825", + pages="1--40", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6825.txt", + key="RFC 6825", + abstract={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]}, + keywords="TED-MIB, ted, mib", + doi="10.17487/RFC6825", + } + +@misc{rfc6826, + author="IJ. {Wijnands (Ed.)} and T. Eckert and N. Leymann and M. Napierala", + title="{Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths}", + howpublished="RFC 6826 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6826", + pages="1--12", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7438", +url="https://www.rfc-editor.org/rfc/rfc6826.txt", + key="RFC 6826", + abstract={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]}, + keywords="", + doi="10.17487/RFC6826", + } + +@misc{rfc6827, + author="A. {Malis (Ed.)} and A. {Lindem (Ed.)} and D. {Papadimitriou (Ed.)}", + title="{Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols}", + howpublished="RFC 6827 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6827", + pages="1--30", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6827.txt", + key="RFC 6827", + abstract={The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). 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. 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. 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 e xtensions 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]}, + keywords="", + doi="10.17487/RFC6827", + } + +@misc{rfc6828, + author="J. Xia", + title="{Content Splicing for RTP Sessions}", + howpublished="RFC 6828 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6828", + pages="1--17", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6828.txt", + key="RFC 6828", + abstract={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. 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.}, + doi="10.17487/RFC6828", + } + +@misc{rfc6829, + author="M. Chen and P. Pan and C. Pignataro and R. Asati", + title="{Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6}", + howpublished="RFC 6829 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6829", + pages="1--8", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8029", +url="https://www.rfc-editor.org/rfc/rfc6829.txt", + key="RFC 6829", + abstract={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. 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]}, + keywords="", + doi="10.17487/RFC6829", + } + +@misc{rfc6830, + author="D. Farinacci and V. Fuller and D. Meyer and D. Lewis", + title="{The Locator/ID Separation Protocol (LISP)}", + howpublished="RFC 6830 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6830", + pages="1--75", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8113", +url="https://www.rfc-editor.org/rfc/rfc6830.txt", + key="RFC 6830", + abstract={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. 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.}, + doi="10.17487/RFC6830", + } + +@misc{rfc6831, + author="D. Farinacci and D. Meyer and J. Zwiebel and S. Venaas", + title="{The Locator/ID Separation Protocol (LISP) for Multicast Environments}", + howpublished="RFC 6831 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6831", + pages="1--28", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6831.txt", + key="RFC 6831", + abstract={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.}, + doi="10.17487/RFC6831", + } + +@misc{rfc6832, + author="D. Lewis and D. Meyer and D. Farinacci and V. Fuller", + title="{Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites}", + howpublished="RFC 6832 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6832", + pages="1--19", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6832.txt", + key="RFC 6832", + abstract={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 LIS P 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.}, + doi="10.17487/RFC6832", + } + +@misc{rfc6833, + author="V. Fuller and D. Farinacci", + title="{Locator/ID Separation Protocol (LISP) Map-Server Interface}", + howpublished="RFC 6833 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6833", + pages="1--13", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6833.txt", + key="RFC 6833", + abstract={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. 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.}, + doi="10.17487/RFC6833", + } + +@misc{rfc6834, + author="L. Iannone and D. Saucez and O. Bonaventure", + title="{Locator/ID Separation Protocol (LISP) Map-Versioning}", + howpublished="RFC 6834 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6834", + pages="1--21", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6834.txt", + key="RFC 6834", + abstract={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.}, + doi="10.17487/RFC6834", + } + +@misc{rfc6835, + author="D. Farinacci and D. Meyer", + title="{The Locator/ID Separation Protocol Internet Groper (LIG)}", + howpublished="RFC 6835 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6835", + pages="1--12", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6835.txt", + key="RFC 6835", + abstract={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.}, + doi="10.17487/RFC6835", + } + +@misc{rfc6836, + author="V. Fuller and D. Farinacci and D. Meyer and D. Lewis", + title="{Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)}", + howpublished="RFC 6836 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6836", + pages="1--25", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6836.txt", + key="RFC 6836", + abstract={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.}, + doi="10.17487/RFC6836", + } + +@misc{rfc6837, + author="E. Lear", + title="{NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database}", + howpublished="RFC 6837 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6837", + pages="1--31", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6837.txt", + key="RFC 6837", + abstract={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.}, + doi="10.17487/RFC6837", + } + +@misc{rfc6838, + author="N. Freed and J. Klensin and T. Hansen", + title="{Media Type Specifications and Registration Procedures}", + howpublished="RFC 6838 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6838", + pages="1--32", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6838.txt", + key="RFC 6838", + abstract={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.}, + doi="10.17487/RFC6838", + } + +@misc{rfc6839, + author="T. Hansen and A. Melnikov", + title="{Additional Media Type Structured Syntax Suffixes}", + howpublished="RFC 6839 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6839", + pages="1--14", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7303", +url="https://www.rfc-editor.org/rfc/rfc6839.txt", + key="RFC 6839", + abstract={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.}, + keywords="structured syntax suffix, media type", + doi="10.17487/RFC6839", + } + +@misc{rfc6840, + author="S. {Weiler (Ed.)} and D. {Blacka (Ed.)}", + title="{Clarifications and Implementation Notes for DNS Security (DNSSEC)}", + howpublished="RFC 6840 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6840", + pages="1--21", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6840.txt", + key="RFC 6840", + abstract={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. 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.}, + keywords="EAP, AAA, reconnect", + doi="10.17487/RFC6840", + } + +@misc{rfc6841, + author="F. Ljunggren and AM. Eklund Lowinder and T. Okubo", + title="{A Framework for DNSSEC Policies and DNSSEC Practice Statements}", + howpublished="RFC 6841 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6841", + pages="1--27", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6841.txt", + key="RFC 6841", + abstract={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. 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.}, + keywords="DNS, DNSSEC, DP, DPS", + doi="10.17487/RFC6841", + } + +@misc{rfc6842, + author="N. Swamy and G. Halwasia and P. Jhingran", + title="{Client Identifier Option in DHCP Server Replies}", + howpublished="RFC 6842 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6842", + pages="1--5", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6842.txt", + key="RFC 6842", + abstract={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]}, + keywords="", + doi="10.17487/RFC6842", + } + +@misc{rfc6843, + author="A. Clark and K. Gross and Q. Wu", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting}", + howpublished="RFC 6843 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6843", + pages="1--9", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6843.txt", + key="RFC 6843", + abstract={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]}, + keywords="Round Trip Delay, End System Delay", + doi="10.17487/RFC6843", + } + +@misc{rfc6844, + author="P. Hallam-Baker and R. Stradling", + title="{DNS Certification Authority Authorization (CAA) Resource Record}", + howpublished="RFC 6844 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6844", + pages="1--18", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6844.txt", + key="RFC 6844", + abstract={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]}, + keywords="DNS, DNSSEC, PKIX", + doi="10.17487/RFC6844", + } + +@misc{rfc6845, + author="N. Sheth and L. Wang and J. Zhang", + title="{OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type}", + howpublished="RFC 6845 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6845", + pages="1--9", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6845.txt", + key="RFC 6845", + abstract={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. This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK]}, + keywords="OSPF, P2MP, Broadcast, Interface", + doi="10.17487/RFC6845", + } + +@misc{rfc6846, + author="G. Pelletier and K. Sandlund and L-E. Jonsson and M. West", + title="{RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)}", + howpublished="RFC 6846 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6846", + pages="1--96", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6846.txt", + key="RFC 6846", + abstract={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. 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. This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC6846", + } + +@misc{rfc6847, + author="D. Melman and T. Mizrahi and D. {Eastlake 3rd}", + title="{Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)}", + howpublished="RFC 6847 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6847", + pages="1--13", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6847.txt", + key="RFC 6847", + abstract={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.}, + keywords="FCoE, FCRB, TRILL, RBridge", + doi="10.17487/RFC6847", + } + +@misc{rfc6848, + author="J. Winterbottom and M. Thomson and R. Barnes and B. Rosen and R. George", + title="{Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)}", + howpublished="RFC 6848 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6848", + pages="1--21", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6848.txt", + key="RFC 6848", + abstract={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]}, + keywords="Extension, Local, Civic, Location, GEOPRIV", + doi="10.17487/RFC6848", + } + +@misc{rfc6849, + author="H. {Kaplan (Ed.)} and K. Hedayat and N. Venna and P. Jones and N. Stratton", + title="{An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback}", + howpublished="RFC 6849 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6849", + pages="1--33", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6849.txt", + key="RFC 6849", + abstract={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.}, + keywords="multimedia, audio, video, RTCP, diagnostic, voip", + doi="10.17487/RFC6849", + } + +@misc{rfc6850, + author="A. Rijhsinghani and K. Zebrose", + title="{Definitions of Managed Objects for Routing Bridges (RBridges)}", + howpublished="RFC 6850 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6850", + pages="1--59", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6850.txt", + key="RFC 6850", + abstract={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]}, + keywords="", + doi="10.17487/RFC6850", + } + +@misc{rfc6851, + author="A. Gulbrandsen and N. {Freed (Ed.)}", + title="{Internet Message Access Protocol (IMAP) - MOVE Extension}", + howpublished="RFC 6851 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6851", + pages="1--8", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6851.txt", + key="RFC 6851", + abstract={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]}, + keywords="IMAP", + doi="10.17487/RFC6851", + } + +@misc{rfc6852, + author="R. Housley and S. Mills and J. Jaffe and B. Aboba and L. St.Amour", + title="{Affirmation of the Modern Paradigm for Standards}", + howpublished="RFC 6852 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6852", + pages="1--5", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6852.txt", + key="RFC 6852", + abstract={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.}, + doi="10.17487/RFC6852", + } + +@misc{rfc6853, + author="J. Brzozowski and J. Tremblay and J. Chen and T. Mrugalski", + title="{DHCPv6 Redundancy Deployment Considerations}", + howpublished="RFC 6853 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6853", + pages="1--16", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6853.txt", + key="RFC 6853", + abstract={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.}, + keywords="DHCPv6, Redundancy, Deployment Considerations", + doi="10.17487/RFC6853", + } + +@misc{rfc6854, + author="B. Leiba", + title="{Update to Internet Message Format to Allow Group Syntax in the ``From:'' and ``Sender:'' Header Fields}", + howpublished="RFC 6854 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6854", + pages="1--9", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6854.txt", + key="RFC 6854", + abstract={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.}, + doi="10.17487/RFC6854", + } + +@misc{rfc6855, + author="P. {Resnick (Ed.)} and C. {Newman (Ed.)} and S. {Shen (Ed.)}", + title="{IMAP Support for UTF-8}", + howpublished="RFC 6855 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6855", + pages="1--12", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6855.txt", + key="RFC 6855", + abstract={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.}, + keywords="IMAP, IDNA", + doi="10.17487/RFC6855", + } + +@misc{rfc6856, + author="R. Gellens and C. Newman and J. Yao and K. Fujiwara", + title="{Post Office Protocol Version 3 (POP3) Support for UTF-8}", + howpublished="RFC 6856 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6856", + pages="1--14", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6856.txt", + key="RFC 6856", + abstract={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.}, + keywords="internationalized", + doi="10.17487/RFC6856", + } + +@misc{rfc6857, + author="K. Fujiwara", + title="{Post-Delivery Message Downgrading for Internationalized Email Messages}", + howpublished="RFC 6857 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6857", + pages="1--20", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6857.txt", + key="RFC 6857", + abstract={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.}, + keywords="EAI, Email Address Internationalization, Downgrade, MAIL", + doi="10.17487/RFC6857", + } + +@misc{rfc6858, + author="A. Gulbrandsen", + title="{Simplified POP and IMAP Downgrading for Internationalized Email}", + howpublished="RFC 6858 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6858", + pages="1--6", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6858.txt", + key="RFC 6858", + abstract={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.}, + doi="10.17487/RFC6858", + } + +@misc{rfc6859, + author="B. Leiba", + title="{Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership}", + howpublished="RFC 6859 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6859", + pages="1--3", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7437", +url="https://www.rfc-editor.org/rfc/rfc6859.txt", + key="RFC 6859", + abstract={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.}, + keywords="nomcom, IAOC", + doi="10.17487/RFC6859", + } + +@misc{rfc6860, + author="Y. Yang and A. Retana and A. Roy", + title="{Hiding Transit-Only Networks in OSPF}", + howpublished="RFC 6860 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6860", + pages="1--13", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6860.txt", + key="RFC 6860", + abstract={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. 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. This document updates RFCs 2328 and 5340. [STANDARDS-TRACK]}, + keywords="", + doi="10.17487/RFC6860", + } + +@misc{rfc6861, + author="I. Dzmanashvili", + title="{The ``create-form'' and ``edit-form'' Link Relations}", + howpublished="RFC 6861 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6861", + pages="1--6", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6861.txt", + key="RFC 6861", + abstract={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.}, + doi="10.17487/RFC6861", + } + +@misc{rfc6862, + author="G. Lebovitz and M. Bhatia and B. Weis", + title="{Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements}", + howpublished="RFC 6862 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6862", + pages="1--26", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6862.txt", + key="RFC 6862", + abstract={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.}, + doi="10.17487/RFC6862", + } + +@misc{rfc6863, + author="S. Hartman and D. Zhang", + title="{Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide}", + howpublished="RFC 6863 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6863", + pages="1--11", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6863.txt", + key="RFC 6863", + abstract={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.}, + doi="10.17487/RFC6863", + } + +@misc{rfc6864, + author="J. Touch", + title="{Updated Specification of the IPv4 ID Field}", + howpublished="RFC 6864 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6864", + pages="1--19", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6864.txt", + key="RFC 6864", + abstract={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]}, + doi="10.17487/RFC6864", + } + +@misc{rfc6865, + author="V. Roca and M. Cunche and J. Lacan and A. Bouabdallah and K. Matsuzono", + title="{Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME}", + howpublished="RFC 6865 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6865", + pages="1--23", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6865.txt", + key="RFC 6865", + abstract={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 <= m <= 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.}, + keywords="Forward Error Correction, Reed-Solomon", + doi="10.17487/RFC6865", + } + +@misc{rfc6866, + author="B. Carpenter and S. Jiang", + title="{Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks}", + howpublished="RFC 6866 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6866", + pages="1--11", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6866.txt", + key="RFC 6866", + abstract={This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.}, + doi="10.17487/RFC6866", + } + +@misc{rfc6867, + author="Y. Nir and Q. Wu", + title="{An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)}", + howpublished="RFC 6867 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6867", + pages="1--9", + year=2013, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6867.txt", + key="RFC 6867", + abstract={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.}, + doi="10.17487/RFC6867", + } + +@misc{rfc6868, + author="C. Daboo", + title="{Parameter Value Encoding in iCalendar and vCard}", + howpublished="RFC 6868 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6868", + pages="1--7", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6868.txt", + key="RFC 6868", + abstract={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.}, + keywords="calendar, contact", + doi="10.17487/RFC6868", + } + +@misc{rfc6869, + author="G. Salgueiro and J. Clarke and P. Saint-Andre", + title="{vCard KIND:device}", + howpublished="RFC 6869 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6869", + pages="1--9", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6869.txt", + key="RFC 6869", + abstract={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]}, + keywords="vCard", + doi="10.17487/RFC6869", + } + +@misc{rfc6870, + author="P. {Muley (Ed.)} and M. {Aissaoui (Ed.)}", + title="{Pseudowire Preferential Forwarding Status Bit}", + howpublished="RFC 6870 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6870", + pages="1--35", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7771", +url="https://www.rfc-editor.org/rfc/rfc6870.txt", + key="RFC 6870", + abstract={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. 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. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.}, + keywords="PW redundancy, active PW, standby PW, primary PW, secondary PW, PW precedence", + doi="10.17487/RFC6870", + } + +@misc{rfc6871, + author="R. Gilman and R. Even and F. Andreasen", + title="{Session Description Protocol (SDP) Media Capabilities Negotiation}", + howpublished="RFC 6871 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6871", + pages="1--55", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6871.txt", + key="RFC 6871", + abstract={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. This document updates the IANA Considerations of RFC 5939.}, + keywords="Session Capabilities, Latent Configurations, Media Format Capability", + doi="10.17487/RFC6871", + } + +@misc{rfc6872, + author="V. {Gurbani (Ed.)} and E. {Burger (Ed.)} and T. Anjali and H. Abdelnur and O. Festor", + title="{The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model}", + howpublished="RFC 6872 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6872", + pages="1--39", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6872.txt", + key="RFC 6872", + abstract={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.}, + keywords="logging, analytics, information model", + doi="10.17487/RFC6872", + } + +@misc{rfc6873, + author="G. Salgueiro and V. Gurbani and A. B. Roach", + title="{Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)}", + howpublished="RFC 6873 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6873", + pages="1--28", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7355", +url="https://www.rfc-editor.org/rfc/rfc6873.txt", + key="RFC 6873", + abstract={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.}, + keywords="SIPCLF", + doi="10.17487/RFC6873", + } + +@misc{rfc6874, + author="B. Carpenter and S. Cheshire and R. Hinden", + title="{Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers}", + howpublished="RFC 6874 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6874", + pages="1--10", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6874.txt", + key="RFC 6874", + abstract={This document describes how the zone identifier of an IPv6 scoped address, defined as <zone\_id> 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.}, + doi="10.17487/RFC6874", + } + +@misc{rfc6875, + author="S. Kamei and T. Momose and T. Inoue and T. Nishitani", + title="{The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan}", + howpublished="RFC 6875 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6875", + pages="1--18", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6875.txt", + key="RFC 6875", + abstract={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.}, + keywords="overlay network, content delivery network, peer-to-peer, traffic engineering, experiments in Japan", + doi="10.17487/RFC6875", + } + +@misc{rfc6876, + author="P. Sangster and N. Cam-Winget and J. Salowey", + title="{A Posture Transport Protocol over TLS (PT-TLS)}", + howpublished="RFC 6876 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6876", + pages="1--44", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6876.txt", + key="RFC 6876", + abstract={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.}, + keywords="Network Endpoint Assessment, NEA", + doi="10.17487/RFC6876", + } + +@misc{rfc6877, + author="M. Mawatari and M. Kawashima and C. Byrne", + title="{464XLAT: Combination of Stateful and Stateless Translation}", + howpublished="RFC 6877 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6877", + pages="1--14", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6877.txt", + key="RFC 6877", + abstract={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.}, + keywords="XLAT, Stateful Translation, Stateless Translation", + doi="10.17487/RFC6877", + } + +@misc{rfc6878, + author="A.B. Roach", + title="{IANA Registry for the Session Initiation Protocol (SIP) ``Priority'' Header Field}", + howpublished="RFC 6878 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6878", + pages="1--3", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6878.txt", + key="RFC 6878", + abstract={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.}, + doi="10.17487/RFC6878", + } + +@misc{rfc6879, + author="S. Jiang and B. Liu and B. Carpenter", + title="{IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods}", + howpublished="RFC 6879 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6879", + pages="1--17", + year=2013, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6879.txt", + key="RFC 6879", + abstract={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.}, + doi="10.17487/RFC6879", + } + +@misc{rfc6880, + author="L. Johansson", + title="{An Information Model for Kerberos Version 5}", + howpublished="RFC 6880 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6880", + pages="1--14", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6880.txt", + key="RFC 6880", + abstract={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.}, + keywords="kerberos, kdc, LDAP, schema", + doi="10.17487/RFC6880", + } + +@misc{rfc6881, + author="B. Rosen and J. Polk", + title="{Best Current Practice for Communications Services in Support of Emergency Calling}", + howpublished="RFC 6881 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6881", + pages="1--28", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7840, 7852", +url="https://www.rfc-editor.org/rfc/rfc6881.txt", + key="RFC 6881", + abstract={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.}, + keywords="SIP, emergency, emergency calls, emergency call, emergency calling, 9-1-1, 1-1-2, ecrit", + doi="10.17487/RFC6881", + } + +@misc{rfc6882, + author="K. {Kumaki (Ed.)} and T. Murai and D. Cheng and S. Matsushima and P. Jiang", + title="{Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)}", + howpublished="RFC 6882 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6882", + pages="1--15", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6882.txt", + key="RFC 6882", + abstract={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. 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.}, + doi="10.17487/RFC6882", + } + +@misc{rfc6883, + author="B. Carpenter and S. Jiang", + title="{IPv6 Guidance for Internet Content Providers and Application Service Providers}", + howpublished="RFC 6883 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6883", + pages="1--24", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6883.txt", + key="RFC 6883", + abstract={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.}, + doi="10.17487/RFC6883", + } + +@misc{rfc6884, + author="Z. Fang", + title="{RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)}", + howpublished="RFC 6884 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6884", + pages="1--21", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6884.txt", + key="RFC 6884", + abstract={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.}, + keywords="EVRC-WB, EVRC-B", + doi="10.17487/RFC6884", + } + +@misc{rfc6885, + author="M. Blanchet and A. Sullivan", + title="{Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)}", + howpublished="RFC 6885 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6885", + pages="1--34", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6885.txt", + key="RFC 6885", + abstract={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.}, + doi="10.17487/RFC6885", + } + +@misc{rfc6886, + author="S. Cheshire and M. Krochmal", + title="{NAT Port Mapping Protocol (NAT-PMP)}", + howpublished="RFC 6886 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6886", + pages="1--33", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6886.txt", + key="RFC 6886", + abstract={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.}, + doi="10.17487/RFC6886", + } + +@misc{rfc6887, + author="D. {Wing (Ed.)} and S. Cheshire and M. Boucadair and R. Penno and P. Selkirk", + title="{Port Control Protocol (PCP)}", + howpublished="RFC 6887 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6887", + pages="1--88", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7488, 7652, 7843", +url="https://www.rfc-editor.org/rfc/rfc6887.txt", + key="RFC 6887", + abstract={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.}, + keywords="NAT, Firewall", + doi="10.17487/RFC6887", + } + +@misc{rfc6888, + author="S. {Perreault (Ed.)} and I. Yamagata and S. Miyakawa and A. Nakagawa and H. Ashida", + title="{Common Requirements for Carrier-Grade NATs (CGNs)}", + howpublished="RFC 6888 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6888", + pages="1--15", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6888.txt", + key="RFC 6888", + abstract={This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.}, + keywords="CGN, NAT", + doi="10.17487/RFC6888", + } + +@misc{rfc6889, + author="R. Penno and T. Saxena and M. Boucadair and S. Sivakumar", + title="{Analysis of Stateful 64 Translation}", + howpublished="RFC 6889 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6889", + pages="1--15", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6889.txt", + key="RFC 6889", + abstract={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.}, + keywords="NAT64, DNS64, NAT-PT, ALG (Application Layer Gateway), NAT traversal, IPv4-IPv6 interconnection, IPv4-IPv6 translation", + doi="10.17487/RFC6889", + } + +@misc{rfc6890, + author="M. Cotton and L. Vegoda and R. {Bonica (Ed.)} and B. Haberman", + title="{Special-Purpose IP Address Registries}", + howpublished="RFC 6890 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6890", + pages="1--23", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8190", +url="https://www.rfc-editor.org/rfc/rfc6890.txt", + key="RFC 6890", + abstract={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.}, + keywords="Internet Protocol, space assignments", + doi="10.17487/RFC6890", + } + +@misc{rfc6891, + author="J. Damas and M. Graff and P. Vixie", + title="{Extension Mechanisms for DNS (EDNS(0))}", + howpublished="RFC 6891 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="6891", + pages="1--16", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6891.txt", + key="RFC 6891", + abstract={The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. 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.}, + keywords="DNS extensions, domain name system, resource records, opt", + doi="10.17487/RFC6891", + } + +@misc{rfc6892, + author="E. Wilde", + title="{The 'describes' Link Relation Type}", + howpublished="RFC 6892 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6892", + pages="1--5", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6892.txt", + key="RFC 6892", + abstract={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.}, + doi="10.17487/RFC6892", + } + +@misc{rfc6893, + author="P. Higgs and P. Szucs", + title="{A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF)}", + howpublished="RFC 6893 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6893", + pages="1--8", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6893.txt", + key="RFC 6893", + abstract={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.}, + doi="10.17487/RFC6893", + } + +@misc{rfc6894, + author="R. Papneja and S. Vapiwala and J. Karthik and S. Poretsky and S. Rao and JL. Le Roux", + title="{Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection}", + howpublished="RFC 6894 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6894", + pages="1--35", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6894.txt", + key="RFC 6894", + abstract={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.}, + doi="10.17487/RFC6894", + } + +@misc{rfc6895, + author="D. {Eastlake 3rd}", + title="{Domain Name System (DNS) IANA Considerations}", + howpublished="RFC 6895 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6895", + pages="1--19", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6895.txt", + key="RFC 6895", + abstract={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.}, + keywords="RRTYPE, RCODE, AFSDB", + doi="10.17487/RFC6895", + } + +@misc{rfc6896, + author="S. Barbato and S. Dorigotti and T. {Fossati (Ed.)}", + title="{SCS: KoanLogic's Secure Cookie Sessions for HTTP}", + howpublished="RFC 6896 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6896", + pages="1--23", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6896.txt", + key="RFC 6896", + abstract={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. 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.}, + keywords="HTTP Secure Cookies", + doi="10.17487/RFC6896", + } + +@misc{rfc6897, + author="M. Scharf and A. Ford", + title="{Multipath TCP (MPTCP) Application Interface Considerations}", + howpublished="RFC 6897 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6897", + pages="1--31", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6897.txt", + key="RFC 6897", + abstract={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.}, + doi="10.17487/RFC6897", + } + +@misc{rfc6898, + author="D. Li and D. Ceccarelli and L. Berger", + title="{Link Management Protocol Behavior Negotiation and Configuration Modifications}", + howpublished="RFC 6898 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6898", + pages="1--11", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6898.txt", + key="RFC 6898", + abstract={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. This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.}, + keywords="LMP", + doi="10.17487/RFC6898", + } + +@misc{rfc6901, + author="P. {Bryan (Ed.)} and K. Zyp and M. {Nottingham (Ed.)}", + title="{JavaScript Object Notation (JSON) Pointer}", + howpublished="RFC 6901 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6901", + pages="1--8", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6901.txt", + key="RFC 6901", + abstract={JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.}, + doi="10.17487/RFC6901", + } + +@misc{rfc6902, + author="P. {Bryan (Ed.)} and M. {Nottingham (Ed.)}", + title="{JavaScript Object Notation (JSON) Patch}", + howpublished="RFC 6902 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6902", + pages="1--18", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6902.txt", + key="RFC 6902", + abstract={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.}, + doi="10.17487/RFC6902", + } + +@misc{rfc6903, + author="J. Snell", + title="{Additional Link Relation Types}", + howpublished="RFC 6903 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6903", + pages="1--6", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6903.txt", + key="RFC 6903", + abstract={This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.}, + keywords="http, link, rel", + doi="10.17487/RFC6903", + } + +@misc{rfc6904, + author="J. Lennox", + title="{Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)}", + howpublished="RFC 6904 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6904", + pages="1--15", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6904.txt", + key="RFC 6904", + abstract={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. 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.}, + keywords="real-time transport protocol, rtp, header extensions, security", + doi="10.17487/RFC6904", + } + +@misc{rfc6905, + author="T. Senevirathne and D. Bond and S. Aldrin and Y. Li and R. Watve", + title="{Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)}", + howpublished="RFC 6905 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6905", + pages="1--13", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6905.txt", + key="RFC 6905", + abstract={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).}, + doi="10.17487/RFC6905", + } + +@misc{rfc6906, + author="E. Wilde", + title="{The 'profile' Link Relation Type}", + howpublished="RFC 6906 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6906", + pages="1--8", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6906.txt", + key="RFC 6906", + abstract={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.}, + keywords="application profile, profile identifier", + doi="10.17487/RFC6906", + } + +@misc{rfc6907, + author="T. Manderson and K. Sriram and R. White", + title="{Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties}", + howpublished="RFC 6907 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6907", + pages="1--31", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6907.txt", + key="RFC 6907", + abstract={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.}, + keywords="Prefix origin validation, Routing security, BGP security", + doi="10.17487/RFC6907", + } + +@misc{rfc6908, + author="Y. Lee and R. Maglione and C. Williams and C. Jacquenet and M. Boucadair", + title="{Deployment Considerations for Dual-Stack Lite}", + howpublished="RFC 6908 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6908", + pages="1--14", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6908.txt", + key="RFC 6908", + abstract={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.}, + doi="10.17487/RFC6908", + } + +@misc{rfc6909, + author="S. {Gundavelli (Ed.)} and X. Zhou and J. Korhonen and G. Feige and R. Koodli", + title="{IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6}", + howpublished="RFC 6909 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6909", + pages="1--14", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6909.txt", + key="RFC 6909", + abstract={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.}, + doi="10.17487/RFC6909", + } + +@misc{rfc6910, + author="D. Worley and M. Huelsemann and R. Jesske and D. Alexeitsev", + title="{Completion of Calls for the Session Initiation Protocol (SIP)}", + howpublished="RFC 6910 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6910", + pages="1--37", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6910.txt", + key="RFC 6910", + abstract={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. 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). 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. The architecture is designed to interoperate well with existing completion of calls solutions in other networks.}, + keywords="call completion, CC, SS7, Signaling System 7, purpose header parameter, m URI parameter, m header parameter, call-completion event package,Â CCBS, CCNR, CCNL, Call-Info header field, Presence Information Data Format, PIDF, P-Asserted-Identity header field", + doi="10.17487/RFC6910", + } + +@misc{rfc6911, + author="W. {Dec (Ed.)} and B. Sarikaya and G. {Zorn (Ed.)} and D. Miles and B. Lourdelet", + title="{RADIUS Attributes for IPv6 Access Networks}", + howpublished="RFC 6911 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6911", + pages="1--15", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6911.txt", + key="RFC 6911", + abstract={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.}, + keywords="AAA, RADIUS, IPv6", + doi="10.17487/RFC6911", + } + +@misc{rfc6912, + author="A. Sullivan and D. Thaler and J. Klensin and O. Kolkman", + title="{Principles for Unicode Code Point Inclusion in Labels in the DNS}", + howpublished="RFC 6912 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6912", + pages="1--12", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6912.txt", + key="RFC 6912", + abstract={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.}, + doi="10.17487/RFC6912", + } + +@misc{rfc6913, + author="D. Hanes and G. Salgueiro and K. Fleming", + title="{Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6913 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6913", + pages="1--9", + year=2013, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6913.txt", + key="RFC 6913", + abstract={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.}, + keywords="media feature tag", + doi="10.17487/RFC6913", + } + +@misc{rfc6914, + author="J. Rosenberg", + title="{SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)}", + howpublished="RFC 6914 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6914", + pages="1--15", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6914.txt", + key="RFC 6914", + abstract={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.}, + keywords="SIP, SIMPLE, presence, IM", + doi="10.17487/RFC6914", + } + +@misc{rfc6915, + author="R. Bellis", + title="{Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)}", + howpublished="RFC 6915 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6915", + pages="1--9", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6915.txt", + key="RFC 6915", + abstract={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. 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. This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement. This document updates RFC 6155 by deprecating the port number elements specified therein.}, + keywords="HELD, Flow", + doi="10.17487/RFC6915", + } + +@misc{rfc6916, + author="R. Gagliano and S. Kent and S. Turner", + title="{Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 6916 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6916", + pages="1--20", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6916.txt", + key="RFC 6916", + abstract={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).}, + keywords="Resource Public Key Infrastructure, RPKI, Algorithm Transition, SIDR, routing security, BGP security", + doi="10.17487/RFC6916", + } + +@misc{rfc6917, + author="C. Boulton and L. Miniero and G. Munson", + title="{Media Resource Brokering}", + howpublished="RFC 6917 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6917", + pages="1--136", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6917.txt", + key="RFC 6917", + abstract={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.}, + doi="10.17487/RFC6917", + } + +@misc{rfc6918, + author="F. Gont and C. Pignataro", + title="{Formally Deprecating Some ICMPv4 Message Types}", + howpublished="RFC 6918 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6918", + pages="1--8", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6918.txt", + key="RFC 6918", + abstract={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.}, + keywords="IANA, IPv4 Options", + doi="10.17487/RFC6918", + } + +@misc{rfc6919, + author="R. Barnes and S. Kent and E. Rescorla", + title="{Further Key Words for Use in RFCs to Indicate Requirement Levels}", + howpublished="RFC 6919 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6919", + pages="1--6", + year=2013, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6919.txt", + key="RFC 6919", + abstract={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: 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.}, + doi="10.17487/RFC6919", + } + +@misc{rfc6920, + author="S. Farrell and D. Kutscher and C. Dannewitz and B. Ohlman and A. Keranen and P. Hallam-Baker", + title="{Naming Things with Hashes}", + howpublished="RFC 6920 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6920", + pages="1--23", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6920.txt", + key="RFC 6920", + abstract={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.}, + keywords="Cryptography, URI, Information Centric Networking", + doi="10.17487/RFC6920", + } + +@misc{rfc6921, + author="R. Hinden", + title="{Design Considerations for Faster-Than-Light (FTL) Communication}", + howpublished="RFC 6921 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6921", + pages="1--7", + year=2013, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6921.txt", + key="RFC 6921", + abstract={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.}, + doi="10.17487/RFC6921", + } + +@misc{rfc6922, + author="Y. Shafranovich", + title="{The application/sql Media Type}", + howpublished="RFC 6922 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6922", + pages="1--5", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6922.txt", + key="RFC 6922", + abstract={This document registers the application/sql media type to be used for the Structured Query Language (SQL).}, + keywords="SQL, MIME", + doi="10.17487/RFC6922", + } + +@misc{rfc6923, + author="R. Winter and E. Gray and H. van Helvoort and M. Betts", + title="{MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions}", + howpublished="RFC 6923 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6923", + pages="1--12", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6923.txt", + key="RFC 6923", + abstract={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).}, + doi="10.17487/RFC6923", + } + +@misc{rfc6924, + author="B. Leiba", + title="{Registration of Second-Level URN Namespaces under ``ietf''}", + howpublished="RFC 6924 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6924", + pages="1--4", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6924.txt", + key="RFC 6924", + abstract={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''.}, + doi="10.17487/RFC6924", + } + +@misc{rfc6925, + author="B. Joshi and R. Desetti and M. Stapp", + title="{The DHCPv4 Relay Agent Identifier Sub-Option}", + howpublished="RFC 6925 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6925", + pages="1--8", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6925.txt", + key="RFC 6925", + abstract={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.}, + keywords="DHCP, relay", + doi="10.17487/RFC6925", + } + +@misc{rfc6926, + author="K. Kinnear and M. Stapp and R. Desetti and B. Joshi and N. Russell and P. Kurapati and B. Volz", + title="{DHCPv4 Bulk Leasequery}", + howpublished="RFC 6926 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6926", + pages="1--41", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7724", +url="https://www.rfc-editor.org/rfc/rfc6926.txt", + key="RFC 6926", + abstract={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.}, + doi="10.17487/RFC6926", + } + +@misc{rfc6927, + author="J. Levine and P. Hoffman", + title="{Variants in Second-Level Names Registered in Top-Level Domains}", + howpublished="RFC 6927 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6927", + pages="1--18", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6927.txt", + key="RFC 6927", + abstract={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.}, + keywords="DNS, variant, TLDs", + doi="10.17487/RFC6927", + } + +@misc{rfc6928, + author="J. Chu and N. Dukkipati and Y. Cheng and M. Mathis", + title="{Increasing TCP's Initial Window}", + howpublished="RFC 6928 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6928", + pages="1--24", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6928.txt", + key="RFC 6928", + abstract={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.}, + doi="10.17487/RFC6928", + } + +@misc{rfc6929, + author="A. DeKok and A. Lior", + title="{Remote Authentication Dial In User Service (RADIUS) Protocol Extensions}", + howpublished="RFC 6929 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6929", + pages="1--68", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6929.txt", + key="RFC 6929", + abstract={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.}, + doi="10.17487/RFC6929", + } + +@misc{rfc6930, + author="D. Guo and S. {Jiang (Ed.)} and R. Despres and R. Maglione", + title="{RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)}", + howpublished="RFC 6930 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6930", + pages="1--12", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6930.txt", + key="RFC 6930", + abstract={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.}, + doi="10.17487/RFC6930", + } + +@misc{rfc6931, + author="D. {Eastlake 3rd}", + title="{Additional XML Security Uniform Resource Identifiers (URIs)}", + howpublished="RFC 6931 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6931", + pages="1--36", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6931.txt", + key="RFC 6931", + abstract={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.}, + doi="10.17487/RFC6931", + } + +@misc{rfc6932, + author="D. {Harkins (Ed.)}", + title="{Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry}", + howpublished="RFC 6932 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6932", + pages="1--12", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6932.txt", + key="RFC 6932", + abstract={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.}, + keywords="elliptic curve, Diffie-Hellman", + doi="10.17487/RFC6932", + } + +@misc{rfc6933, + author="A. Bierman and D. Romascanu and J. Quittek and M. Chandramouli", + title="{Entity MIB (Version 4)}", + howpublished="RFC 6933 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6933", + pages="1--76", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6933.txt", + key="RFC 6933", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single 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.}, + keywords="management information base, snmp, simple network management protocol", + doi="10.17487/RFC6933", + } + +@misc{rfc6934, + author="N. {Bitar (Ed.)} and S. {Wadhwa (Ed.)} and T. Haag and H. Li", + title="{Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)}", + howpublished="RFC 6934 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6934", + pages="1--39", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6934.txt", + key="RFC 6934", + abstract={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-r elated operations within those network elements to meet performance objectives.}, + doi="10.17487/RFC6934", + } + +@misc{rfc6935, + author="M. Eubanks and P. Chimento and M. Westerlund", + title="{IPv6 and UDP Checksums for Tunneled Packets}", + howpublished="RFC 6935 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6935", + pages="1--12", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6935.txt", + key="RFC 6935", + abstract={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.}, + keywords="Tunnel, Encapsulation, Integrity, Packet Corruption, Middlebox", + doi="10.17487/RFC6935", + } + +@misc{rfc6936, + author="G. Fairhurst and M. Westerlund", + title="{Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums}", + howpublished="RFC 6936 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6936", + pages="1--40", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6936.txt", + key="RFC 6936", + abstract={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.}, + doi="10.17487/RFC6936", + } + +@misc{rfc6937, + author="M. Mathis and N. Dukkipati and Y. Cheng", + title="{Proportional Rate Reduction for TCP}", + howpublished="RFC 6937 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6937", + pages="1--16", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6937.txt", + key="RFC 6937", + abstract={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.}, + keywords="TCP loss recovery, packet conservation, self clock", + doi="10.17487/RFC6937", + } + +@misc{rfc6938, + author="J. Scudder", + title="{Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID\_PATH / CLUSTER\_ID}", + howpublished="RFC 6938 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6938", + pages="1--3", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6938.txt", + key="RFC 6938", + abstract={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.}, + keywords="BGP", + doi="10.17487/RFC6938", + } + +@misc{rfc6939, + author="G. Halwasia and S. Bhandari and W. Dec", + title="{Client Link-Layer Address Option in DHCPv6}", + howpublished="RFC 6939 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6939", + pages="1--7", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6939.txt", + key="RFC 6939", + abstract={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.}, + doi="10.17487/RFC6939", + } + +@misc{rfc6940, + author="C. Jennings and B. {Lowekamp (Ed.)} and E. Rescorla and S. Baset and H. Schulzrinne", + title="{REsource LOcation And Discovery (RELOAD) Base Protocol}", + howpublished="RFC 6940 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6940", + pages="1--176", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6940.txt", + key="RFC 6940", + abstract={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.}, + keywords="p2p, dht, p2psip, chord, peer to peer", + doi="10.17487/RFC6940", + } + +@misc{rfc6941, + author="L. {Fang (Ed.)} and B. {Niven-Jenkins (Ed.)} and S. {Mansfield (Ed.)} and R. {Graveman (Ed.)}", + title="{MPLS Transport Profile (MPLS-TP) Security Framework}", + howpublished="RFC 6941 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6941", + pages="1--15", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6941.txt", + key="RFC 6941", + abstract={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. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Stan dardization 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.}, + keywords="threats, mitigation, defensive techniques", + doi="10.17487/RFC6941", + } + +@misc{rfc6942, + author="J. Bournelle and L. Morand and S. Decugis and Q. Wu and G. Zorn", + title="{Diameter Support for the EAP Re-authentication Protocol (ERP)}", + howpublished="RFC 6942 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6942", + pages="1--18", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6942.txt", + key="RFC 6942", + abstract={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.}, + doi="10.17487/RFC6942", + } + +@misc{rfc6943, + author="D. {Thaler (Ed.)}", + title="{Issues in Identifier Comparison for Security Purposes}", + howpublished="RFC 6943 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6943", + pages="1--26", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6943.txt", + key="RFC 6943", + abstract={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.}, + keywords="Canonicalization, Normalization, Hostname, URI, IRI", + doi="10.17487/RFC6943", + } + +@misc{rfc6944, + author="S. Rose", + title="{Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status}", + howpublished="RFC 6944 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6944", + pages="1--7", + year=2013, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6944.txt", + key="RFC 6944", + abstract={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.}, + doi="10.17487/RFC6944", + } + +@misc{rfc6945, + author="R. Bush and B. Wijnen and K. Patel and M. Baer", + title="{Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol}", + howpublished="RFC 6945 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6945", + pages="1--25", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6945.txt", + key="RFC 6945", + abstract={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.}, + doi="10.17487/RFC6945", + } + +@misc{rfc6946, + author="F. Gont", + title="{Processing of IPv6 ``Atomic'' Fragments}", + howpublished="RFC 6946 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6946", + pages="1--9", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6946.txt", + key="RFC 6946", + abstract={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 independe ntly of any other fragments, thus completely eliminating the aforementioned attack vector.}, + keywords="fragmentation, attacks, vulnerabilities, atomic fragments", + doi="10.17487/RFC6946", + } + +@misc{rfc6947, + author="M. Boucadair and H. Kaplan and R. Gilman and S. Veikkolainen", + title="{The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute}", + howpublished="RFC 6947 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6947", + pages="1--24", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6947.txt", + key="RFC 6947", + abstract={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. 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.}, + doi="10.17487/RFC6947", + } + +@misc{rfc6948, + author="A. Keranen and J. Arkko", + title="{Some Measurements on World IPv6 Day from an End-User Perspective}", + howpublished="RFC 6948 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6948", + pages="1--11", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6948.txt", + key="RFC 6948", + abstract={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.}, + doi="10.17487/RFC6948", + } + +@misc{rfc6949, + author="H. Flanagan and N. Brownlee", + title="{RFC Series Format Requirements and Future Development}", + howpublished="RFC 6949 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6949", + pages="1--14", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6949.txt", + key="RFC 6949", + abstract={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.}, + doi="10.17487/RFC6949", + } + +@misc{rfc6950, + author="J. Peterson and O. Kolkman and H. Tschofenig and B. Aboba", + title="{Architectural Considerations on Application Features in the DNS}", + howpublished="RFC 6950 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6950", + pages="1--31", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6950.txt", + key="RFC 6950", + abstract={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.}, + doi="10.17487/RFC6950", + } + +@misc{rfc6951, + author="M. Tuexen and R. Stewart", + title="{UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication}", + howpublished="RFC 6951 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6951", + pages="1--12", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6951.txt", + key="RFC 6951", + abstract={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. 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. This document covers only end-hosts and not tunneling (egress or ingress) endpoints.}, + doi="10.17487/RFC6951", + } + +@misc{rfc6952, + author="M. Jethanandani and K. Patel and L. Zheng", + title="{Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide}", + howpublished="RFC 6952 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6952", + pages="1--17", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6952.txt", + key="RFC 6952", + abstract={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.}, + keywords="key, authentication, routing, DoS", + doi="10.17487/RFC6952", + } + +@misc{rfc6953, + author="A. {Mancuso (Ed.)} and S. Probasco and B. Patil", + title="{Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements}", + howpublished="RFC 6953 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6953", + pages="1--23", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6953.txt", + key="RFC 6953", + abstract={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.}, + doi="10.17487/RFC6953", + } + +@misc{rfc6954, + author="J. Merkle and M. Lochter", + title="{Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 6954 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6954", + pages="1--11", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6954.txt", + key="RFC 6954", + abstract={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).}, + keywords="IKE, Elliptic Curve", + doi="10.17487/RFC6954", + } + +@misc{rfc6955, + author="J. Schaad and H. Prafullchandra", + title="{Diffie-Hellman Proof-of-Possession Algorithms}", + howpublished="RFC 6955 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6955", + pages="1--43", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6955.txt", + key="RFC 6955", + abstract={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. This document obsoletes RFC 2875.}, + keywords="POP, ECDH, DH", + doi="10.17487/RFC6955", + } + +@misc{rfc6956, + author="W. Wang and E. Haleplidis and K. Ogawa and C. Li and J. Halpern", + title="{Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library}", + howpublished="RFC 6956 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6956", + pages="1--111", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6956.txt", + key="RFC 6956", + abstract={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.}, + keywords="ForCES, LFB, Library", + doi="10.17487/RFC6956", + } + +@misc{rfc6957, + author="F. Costa and J-M. {Combes (Ed.)} and X. Pougnard and H. Li", + title="{Duplicate Address Detection Proxy}", + howpublished="RFC 6957 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6957", + pages="1--16", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6957.txt", + key="RFC 6957", + abstract={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.}, + keywords="IPv6, SLAAC, DAD, SAVI", + doi="10.17487/RFC6957", + } + +@misc{rfc6958, + author="A. Clark and S. Zhang and J. Zhao and Q. {Wu (Ed.)}", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting}", + howpublished="RFC 6958 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6958", + pages="1--16", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6958.txt", + key="RFC 6958", + abstract={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.}, + keywords="Real Time Control Protocol", + doi="10.17487/RFC6958", + } + +@misc{rfc6959, + author="D. McPherson and F. Baker and J. Halpern", + title="{Source Address Validation Improvement (SAVI) Threat Scope}", + howpublished="RFC 6959 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6959", + pages="1--25", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6959.txt", + key="RFC 6959", + abstract={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.}, + doi="10.17487/RFC6959", + } + +@misc{rfc6960, + author="S. Santesson and M. Myers and R. Ankney and A. Malpani and S. Galperin and C. Adams", + title="{X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP}", + howpublished="RFC 6960 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6960", + pages="1--41", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6960.txt", + key="RFC 6960", + abstract={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.}, + keywords="PKIX, digital security, ocsp", + doi="10.17487/RFC6960", + } + +@misc{rfc6961, + author="Y. Pettersen", + title="{The Transport Layer Security (TLS) Multiple Certificate Status Request Extension}", + howpublished="RFC 6961 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6961", + pages="1--10", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8446", +url="https://www.rfc-editor.org/rfc/rfc6961.txt", + key="RFC 6961", + abstract={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.}, + keywords="RFC 6066, RFC 2560, RFC 6960, RFC 5246, OCSP, OCSP stapling, multi-stapling, certificate status checking, revocation information, status\_request, status\_request\_v2", + doi="10.17487/RFC6961", + } + +@misc{rfc6962, + author="B. Laurie and A. Langley and E. Kasper", + title="{Certificate Transparency}", + howpublished="RFC 6962 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6962", + pages="1--27", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6962.txt", + key="RFC 6962", + abstract={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. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.}, + keywords="TLS certificates", + doi="10.17487/RFC6962", + } + +@misc{rfc6963, + author="P. Saint-Andre", + title="{A Uniform Resource Name (URN) Namespace for Examples}", + howpublished="RFC 6963 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6963", + pages="1--7", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6963.txt", + key="RFC 6963", + abstract={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.}, + keywords="URN, examples, documentation", + doi="10.17487/RFC6963", + } + +@misc{rfc6964, + author="F. Templin", + title="{Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)}", + howpublished="RFC 6964 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6964", + pages="1--20", + year=2013, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6964.txt", + key="RFC 6964", + abstract={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).}, + keywords="IPv6, IPv4, IPv6/IPv4, IPv6-in-IPv4, tunnel, automatic, isatap, enterprise, site", + doi="10.17487/RFC6964", + } + +@misc{rfc6965, + author="L. {Fang (Ed.)} and N. Bitar and R. Zhang and M. Daikoku and P. Pan", + title="{MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design}", + howpublished="RFC 6965 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6965", + pages="1--16", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6965.txt", + key="RFC 6965", + abstract={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.}, + doi="10.17487/RFC6965", + } + +@misc{rfc6967, + author="M. Boucadair and J. Touch and P. Levis and R. Penno", + title="{Analysis of Potential Solutions for Revealing a Host Identifier (HOST\_ID) in Shared Address Deployments}", + howpublished="RFC 6967 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6967", + pages="1--24", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6967.txt", + key="RFC 6967", + abstract={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. 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.}, + keywords="NAT, Host Identifier", + doi="10.17487/RFC6967", + } + +@misc{rfc6968, + author="V. Roca and B. Adamson", + title="{FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols}", + howpublished="RFC 6968 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6968", + pages="1--40", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6968.txt", + key="RFC 6968", + abstract={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.}, + doi="10.17487/RFC6968", + } + +@misc{rfc6969, + author="A. Retana and D. Cheng", + title="{OSPFv3 Instance ID Registry Update}", + howpublished="RFC 6969 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6969", + pages="1--4", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6969.txt", + key="RFC 6969", + abstract={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.}, + doi="10.17487/RFC6969", + } + +@misc{rfc6970, + author="M. Boucadair and R. Penno and D. Wing", + title="{Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)}", + howpublished="RFC 6970 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6970", + pages="1--23", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6970.txt", + key="RFC 6970", + abstract={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.}, + keywords="UPnP, pinhole, PCP, mapping, NAT control, interworking", + doi="10.17487/RFC6970", + } + +@misc{rfc6971, + author="U. {Herberg (Ed.)} and A. Cardenas and T. Iwao and M. Dow and S. Cespedes", + title="{Depth-First Forwarding (DFF) in Unreliable Networks}", + howpublished="RFC 6971 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6971", + pages="1--41", + year=2013, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6971.txt", + key="RFC 6971", + abstract={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.}, + keywords="DFF, Depth first forwarding, IPv6, Forwarding plane, Lossy networks, Reliability", + doi="10.17487/RFC6971", + } + +@misc{rfc6972, + author="Y. Zhang and N. Zong", + title="{Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)}", + howpublished="RFC 6972 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6972", + pages="1--22", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6972.txt", + key="RFC 6972", + abstract={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.}, + keywords="P2P", + doi="10.17487/RFC6972", + } + +@misc{rfc6973, + author="A. Cooper and H. Tschofenig and B. Aboba and J. Peterson and J. Morris and M. Hansen and R. Smith", + title="{Privacy Considerations for Internet Protocols}", + howpublished="RFC 6973 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6973", + pages="1--36", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6973.txt", + key="RFC 6973", + abstract={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.}, + keywords="Disclosure, Anonymity, Pseudonymity, Confidentiality, Identity", + doi="10.17487/RFC6973", + } + +@misc{rfc6974, + author="Y. Weingarten and S. Bryant and D. Ceccarelli and D. Caviglia and F. Fondelli and M. Corsi and B. Wu and X. Dai", + title="{Applicability of MPLS Transport Profile for Ring Topologies}", + howpublished="RFC 6974 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6974", + pages="1--30", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6974.txt", + key="RFC 6974", + abstract={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.}, + doi="10.17487/RFC6974", + } + +@misc{rfc6975, + author="S. Crocker and S. Rose", + title="{Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)}", + howpublished="RFC 6975 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6975", + pages="1--9", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6975.txt", + key="RFC 6975", + abstract={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.}, + keywords="DNS, DNSSEC, EDNS", + doi="10.17487/RFC6975", + } + +@misc{rfc6976, + author="M. Shand and S. Bryant and S. Previdi and C. Filsfils and P. Francois and O. Bonaventure", + title="{Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach}", + howpublished="RFC 6976 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6976", + pages="1--28", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6976.txt", + key="RFC 6976", + abstract={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. 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. 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. The technology described in this document has been subject to extensive s imulation 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.}, + doi="10.17487/RFC6976", + } + +@misc{rfc6977, + author="M. Boucadair and X. Pougnard", + title="{Triggering DHCPv6 Reconfiguration from Relay Agents}", + howpublished="RFC 6977 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6977", + pages="1--13", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6977.txt", + key="RFC 6977", + abstract={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.}, + keywords="Reconfigure-Request, Reconfigure-Reply, Link Address Option", + doi="10.17487/RFC6977", + } + +@misc{rfc6978, + author="J. Touch", + title="{A TCP Authentication Option Extension for NAT Traversal}", + howpublished="RFC 6978 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6978", + pages="1--6", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6978.txt", + key="RFC 6978", + abstract={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.}, + keywords="TCP-AO", + doi="10.17487/RFC6978", + } + +@misc{rfc6979, + author="T. Pornin", + title="{Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)}", + howpublished="RFC 6979 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6979", + pages="1--79", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6979.txt", + key="RFC 6979", + abstract={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.}, + keywords="dsa, ecdsa, digital signature, deterministic", + doi="10.17487/RFC6979", + } + +@misc{rfc6980, + author="F. Gont", + title="{Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery}", + howpublished="RFC 6980 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6980", + pages="1--10", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6980.txt", + key="RFC 6980", + abstract={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.}, + keywords="vulnerabilities, evasion, monitoring", + doi="10.17487/RFC6980", + } + +@misc{rfc6981, + author="S. Bryant and S. Previdi and M. Shand", + title="{A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses}", + howpublished="RFC 6981 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6981", + pages="1--34", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6981.txt", + key="RFC 6981", + abstract={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. 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.}, + keywords="not-via", + doi="10.17487/RFC6981", + } + +@misc{rfc6982, + author="Y. Sheffer and A. Farrel", + title="{Improving Awareness of Running Code: The Implementation Status Section}", + howpublished="RFC 6982 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6982", + pages="1--9", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7942", +url="https://www.rfc-editor.org/rfc/rfc6982.txt", + key="RFC 6982", + abstract={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. 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.}, + doi="10.17487/RFC6982", + } + +@misc{rfc6983, + author="R. van Brandenburg and O. van Deventer and F. Le Faucheur and K. Leung", + title="{Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)}", + howpublished="RFC 6983 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6983", + pages="1--45", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6983.txt", + key="RFC 6983", + abstract={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.}, + keywords="video, caching, HTTP, content delivery", + doi="10.17487/RFC6983", + } + +@misc{rfc6984, + author="W. Wang and K. Ogawa and E. Haleplidis and M. Gao and J. Hadi Salim", + title="{Interoperability Report for Forwarding and Control Element Separation (ForCES)}", + howpublished="RFC 6984 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6984", + pages="1--29", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6984.txt", + key="RFC 6984", + abstract={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.}, + doi="10.17487/RFC6984", + } + +@misc{rfc6985, + author="A. Morton", + title="{IMIX Genome: Specification of Variable Packet Sizes for Additional Testing}", + howpublished="RFC 6985 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6985", + pages="1--10", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6985.txt", + key="RFC 6985", + abstract={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.}, + keywords="Traffic, Pattern, Benchmarking", + doi="10.17487/RFC6985", + } + +@misc{rfc6986, + author="V. {Dolmatov (Ed.)} and A. Degtyarev", + title="{GOST R 34.11-2012: Hash Function}", + howpublished="RFC 6986 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6986", + pages="1--40", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6986.txt", + key="RFC 6986", + abstract={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.}, + doi="10.17487/RFC6986", + } + +@misc{rfc6987, + author="A. Retana and L. Nguyen and A. Zinin and R. White and D. McPherson", + title="{OSPF Stub Router Advertisement}", + howpublished="RFC 6987 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6987", + pages="1--7", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6987.txt", + key="RFC 6987", + abstract={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. This document obsoletes RFC 3137.}, + keywords="ospf stub", + doi="10.17487/RFC6987", + } + +@misc{rfc6988, + author="J. {Quittek (Ed.)} and M. Chandramouli and R. Winter and T. Dietz and B. Claise", + title="{Requirements for Energy Management}", + howpublished="RFC 6988 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6988", + pages="1--28", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6988.txt", + key="RFC 6988", + abstract={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. 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.}, + keywords="monitoring functions, control functions", + doi="10.17487/RFC6988", + } + +@misc{rfc6989, + author="Y. Sheffer and S. Fluhrer", + title="{Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 6989 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6989", + pages="1--10", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6989.txt", + key="RFC 6989", + abstract={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.}, + keywords="Elliptic Curve cryptography, secret key reuse, recipient tests", + doi="10.17487/RFC6989", + } + +@misc{rfc6990, + author="R. Huang and Q. Wu and H. Asaeda and G. Zorn", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting}", + howpublished="RFC 6990 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6990", + pages="1--11", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6990.txt", + key="RFC 6990", + abstract={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.}, + keywords="RTCP, XR, MPEG2, PSI, Decodability", + doi="10.17487/RFC6990", + } + +@misc{rfc6991, + author="J. {Schoenwaelder (Ed.)}", + title="{Common YANG Data Types}", + howpublished="RFC 6991 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6991", + pages="1--30", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6991.txt", + key="RFC 6991", + abstract={This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.}, + keywords="YANG, data model, netconf", + doi="10.17487/RFC6991", + } + +@misc{rfc6992, + author="D. Cheng and M. Boucadair and A. Retana", + title="{Routing for IPv4-Embedded IPv6 Packets}", + howpublished="RFC 6992 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6992", + pages="1--15", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6992.txt", + key="RFC 6992", + abstract={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.}, + doi="10.17487/RFC6992", + } + +@misc{rfc6993, + author="P. Saint-Andre", + title="{Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)}", + howpublished="RFC 6993 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="6993", + pages="1--5", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6993.txt", + key="RFC 6993", + abstract={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).}, + keywords="SIP, Call-Info, header field, Instant Messaging, Presence", + doi="10.17487/RFC6993", + } + +@misc{rfc6994, + author="J. Touch", + title="{Shared Use of Experimental TCP Options}", + howpublished="RFC 6994 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="6994", + pages="1--11", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6994.txt", + key="RFC 6994", + abstract={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.}, + doi="10.17487/RFC6994", + } + +@misc{rfc6996, + author="J. Mitchell", + title="{Autonomous System (AS) Reservation for Private Use}", + howpublished="RFC 6996 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="6996", + pages="1--4", + year=2013, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6996.txt", + key="RFC 6996", + abstract={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.}, + keywords="asn", + doi="10.17487/RFC6996", + } + +@misc{rfc6997, + author="M. {Goyal (Ed.)} and E. Baccelli and M. Philipp and A. Brandt and J. Martocci", + title="{Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks}", + howpublished="RFC 6997 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6997", + pages="1--40", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6997.txt", + key="RFC 6997", + abstract={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.}, + keywords="P2P Routing, RPL, ROLL", + doi="10.17487/RFC6997", + } + +@misc{rfc6998, + author="M. {Goyal (Ed.)} and E. Baccelli and A. Brandt and J. Martocci", + title="{A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network}", + howpublished="RFC 6998 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="6998", + pages="1--29", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc6998.txt", + key="RFC 6998", + abstract={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.}, + keywords="Measurement, Route Quality, P2P Routes, RPL, ROLL", + doi="10.17487/RFC6998", + } + +@misc{rfc7001, + author="M. Kucherawy", + title="{Message Header Field for Indicating Message Authentication Status}", + howpublished="RFC 7001 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7001", + pages="1--43", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7601, updated by RFC 7410", +url="https://www.rfc-editor.org/rfc/rfc7001.txt", + key="RFC 7001", + abstract={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.}, + keywords="DKIM, DomainKeys, SenderID, SPF, ADSP, ATPS, VBR, Authentication, Reputation", + doi="10.17487/RFC7001", + } + +@misc{rfc7002, + author="A. Clark and G. Zorn and Q. Wu", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting}", + howpublished="RFC 7002 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7002", + pages="1--12", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7002.txt", + key="RFC 7002", + abstract={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.}, + doi="10.17487/RFC7002", + } + +@misc{rfc7003, + author="A. Clark and R. Huang and Q. {Wu (Ed.)}", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting}", + howpublished="RFC 7003 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7003", + pages="1--14", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7003.txt", + key="RFC 7003", + abstract={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.}, + keywords="Real Time Control Protocol", + doi="10.17487/RFC7003", + } + +@misc{rfc7004, + author="G. Zorn and R. Schott and Q. {Wu (Ed.)} and R. Huang", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting}", + howpublished="RFC 7004 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7004", + pages="1--21", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7004.txt", + key="RFC 7004", + abstract={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.}, + keywords="RTCP XR, Summary Statistics, Burst/Gap Loss, Burst/Gap Discard, Frame Impairment", + doi="10.17487/RFC7004", + } + +@misc{rfc7005, + author="A. Clark and V. Singh and Q. Wu", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting}", + howpublished="RFC 7005 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7005", + pages="1--14", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7005.txt", + key="RFC 7005", + abstract={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.}, + doi="10.17487/RFC7005", + } + +@misc{rfc7006, + author="M. Garcia-Martin and S. Veikkolainen and R. Gilman", + title="{Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)}", + howpublished="RFC 7006 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7006", + pages="1--22", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7006.txt", + key="RFC 7006", + abstract={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. 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).}, + keywords="title capability, connection data capability, bandwidth capability", + doi="10.17487/RFC7006", + } + +@misc{rfc7007, + author="T. Terriberry", + title="{Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)}", + howpublished="RFC 7007 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7007", + pages="1--4", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7007.txt", + key="RFC 7007", + abstract={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.}, + doi="10.17487/RFC7007", + } + +@misc{rfc7008, + author="S. Kiyomoto and W. Shin", + title="{A Description of the KCipher-2 Encryption Algorithm}", + howpublished="RFC 7008 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7008", + pages="1--37", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7008.txt", + key="RFC 7008", + abstract={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.}, + keywords="encryption, stream cipher, cipher", + doi="10.17487/RFC7008", + } + +@misc{rfc7009, + author="T. {Lodderstedt (Ed.)} and S. Dronia and M. Scurtescu", + title="{OAuth 2.0 Token Revocation}", + howpublished="RFC 7009 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7009", + pages="1--11", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7009.txt", + key="RFC 7009", + abstract={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.}, + doi="10.17487/RFC7009", + } + +@misc{rfc7010, + author="B. Liu and S. Jiang and B. Carpenter and S. Venaas and W. George", + title="{IPv6 Site Renumbering Gap Analysis}", + howpublished="RFC 7010 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7010", + pages="1--26", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7010.txt", + key="RFC 7010", + abstract={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.}, + doi="10.17487/RFC7010", + } + +@misc{rfc7011, + author="B. {Claise (Ed.)} and B. {Trammell (Ed.)} and P. Aitken", + title="{Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information}", + howpublished="RFC 7011 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="7011", + pages="1--76", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7011.txt", + key="RFC 7011", + abstract={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.}, + doi="10.17487/RFC7011", + } + +@misc{rfc7012, + author="B. {Claise (Ed.)} and B. {Trammell (Ed.)}", + title="{Information Model for IP Flow Information Export (IPFIX)}", + howpublished="RFC 7012 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7012", + pages="1--24", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7012.txt", + key="RFC 7012", + abstract={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.}, + doi="10.17487/RFC7012", + } + +@misc{rfc7013, + author="B. Trammell and B. Claise", + title="{Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements}", + howpublished="RFC 7013 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7013", + pages="1--32", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7013.txt", + key="RFC 7013", + abstract={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.}, + keywords="IE-DOCTORS, IANA", + doi="10.17487/RFC7013", + } + +@misc{rfc7014, + author="S. D'Antonio and T. Zseby and C. Henke and L. Peluso", + title="{Flow Selection Techniques}", + howpublished="RFC 7014 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7014", + pages="1--33", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7014.txt", + key="RFC 7014", + abstract={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.}, + doi="10.17487/RFC7014", + } + +@misc{rfc7015, + author="B. Trammell and A. Wagner and B. Claise", + title="{Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol}", + howpublished="RFC 7015 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7015", + pages="1--49", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7015.txt", + key="RFC 7015", + abstract={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.}, + keywords="Flow metering, Flow measurement, IPFIX mediator", + doi="10.17487/RFC7015", + } + +@misc{rfc7016, + author="M. Thornburgh", + title="{Adobe's Secure Real-Time Media Flow Protocol}", + howpublished="RFC 7016 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7016", + pages="1--113", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7016.txt", + key="RFC 7016", + abstract={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.}, + keywords="RTMFP", + doi="10.17487/RFC7016", + } + +@misc{rfc7017, + author="R. Sparks", + title="{IMAP Access to IETF Email List Archives}", + howpublished="RFC 7017 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7017", + pages="1--5", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7017.txt", + key="RFC 7017", + abstract={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.}, + doi="10.17487/RFC7017", + } + +@misc{rfc7018, + author="V. Manral and S. Hanna", + title="{Auto-Discovery VPN Problem Statement and Requirements}", + howpublished="RFC 7018 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7018", + pages="1--12", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7018.txt", + key="RFC 7018", + abstract={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. 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.}, + keywords="IPsec, Overlay, SDN, IKE", + doi="10.17487/RFC7018", + } + +@misc{rfc7019, + author="J. Buford and M. {Kolberg (Ed.)}", + title="{Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)}", + howpublished="RFC 7019 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7019", + pages="1--41", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7019.txt", + key="RFC 7019", + abstract={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. This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).}, + keywords="application-layer multicast", + doi="10.17487/RFC7019", + } + +@misc{rfc7020, + author="R. Housley and J. Curran and G. Huston and D. Conrad", + title="{The Internet Numbers Registry System}", + howpublished="RFC 7020 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7020", + pages="1--9", + year=2013, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7020.txt", + key="RFC 7020", + abstract={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. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. 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.}, + doi="10.17487/RFC7020", + } + +@misc{rfc7021, + author="C. {Donley (Ed.)} and L. Howard and V. Kuarsingh and J. Berg and J. Doshi", + title="{Assessing the Impact of Carrier-Grade NAT on Network Applications}", + howpublished="RFC 7021 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7021", + pages="1--29", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7021.txt", + key="RFC 7021", + abstract={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.}, + keywords="CGN, NAT444, DS-Lite, Dual-Stack Lite, IPv4, NAT, IPv6, LSN transition", + doi="10.17487/RFC7021", + } + +@misc{rfc7022, + author="A. Begen and C. Perkins and D. Wing and E. Rescorla", + title="{Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)}", + howpublished="RFC 7022 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7022", + pages="1--10", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7022.txt", + key="RFC 7022", + abstract={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 (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.}, + doi="10.17487/RFC7022", + } + +@misc{rfc7023, + author="D. {Mohan (Ed.)} and N. {Bitar (Ed.)} and A. {Sajassi (Ed.)} and S. DeLord and P. Niger and R. Qiu", + title="{MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking}", + howpublished="RFC 7023 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7023", + pages="1--23", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7023.txt", + key="RFC 7023", + abstract={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.}, + doi="10.17487/RFC7023", + } + +@misc{rfc7024, + author="H. Jeng and J. Uttaro and L. Jalil and B. Decraene and Y. Rekhter and R. Aggarwal", + title="{Virtual Hub-and-Spoke in BGP/MPLS VPNs}", + howpublished="RFC 7024 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7024", + pages="1--25", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7024.txt", + key="RFC 7024", + abstract={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. 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.}, + doi="10.17487/RFC7024", + } + +@misc{rfc7025, + author="T. Otani and K. Ogaki and D. Caviglia and F. Zhang and C. Margaria", + title="{Requirements for GMPLS Applications of PCE}", + howpublished="RFC 7025 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7025", + pages="1--12", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7025.txt", + key="RFC 7025", + abstract={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.}, + keywords="Path Computation, CSPF, PCC, Traffic Engineering, TE", + doi="10.17487/RFC7025", + } + +@misc{rfc7026, + author="A. Farrel and S. Bryant", + title="{Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel}", + howpublished="RFC 7026 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7026", + pages="1--5", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7026.txt", + key="RFC 7026", + abstract={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 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. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.}, + keywords="ACH, G-ACh, Pseudowire, PW, MPLS-TP", + doi="10.17487/RFC7026", + } + +@misc{rfc7027, + author="J. Merkle and M. Lochter", + title="{Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)}", + howpublished="RFC 7027 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7027", + pages="1--10", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7027.txt", + key="RFC 7027", + abstract={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.}, + keywords="TLS, Elliptic Curve Cryptography", + doi="10.17487/RFC7027", + } + +@misc{rfc7028, + author="JC. Zuniga and LM. Contreras and CJ. Bernardos and S. Jeon and Y. Kim", + title="{Multicast Mobility Routing Optimizations for Proxy Mobile IPv6}", + howpublished="RFC 7028 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7028", + pages="1--29", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7028.txt", + key="RFC 7028", + abstract={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.}, + keywords="multimob, PMIPv6, MTMA, selector, MLD, IGMP", + doi="10.17487/RFC7028", + } + +@misc{rfc7029, + author="S. Hartman and M. Wasserman and D. Zhang", + title="{Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding}", + howpublished="RFC 7029 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7029", + pages="1--19", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7029.txt", + key="RFC 7029", + abstract={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.}, + keywords="MITM, man-in-the-middle, EMSK crypto binding, Extended Master Session Key, tunnel", + doi="10.17487/RFC7029", + } + +@misc{rfc7030, + author="M. {Pritikin (Ed.)} and P. {Yee (Ed.)} and D. {Harkins (Ed.)}", + title="{Enrollment over Secure Transport}", + howpublished="RFC 7030 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7030", + pages="1--53", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7030.txt", + key="RFC 7030", + abstract={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.}, + keywords="pki, est", + doi="10.17487/RFC7030", + } + +@misc{rfc7031, + author="T. Mrugalski and K. Kinnear", + title="{DHCPv6 Failover Requirements}", + howpublished="RFC 7031 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7031", + pages="1--17", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7031.txt", + key="RFC 7031", + abstract={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.}, + keywords="DHCPv6, Failover", + doi="10.17487/RFC7031", + } + +@misc{rfc7032, + author="T. {Beckhaus (Ed.)} and B. Decraene and K. Tiruveedhula and M. {Konstantynowicz (Ed.)} and L. Martini", + title="{LDP Downstream-on-Demand in Seamless MPLS}", + howpublished="RFC 7032 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7032", + pages="1--35", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7032.txt", + key="RFC 7032", + abstract={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. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.}, + doi="10.17487/RFC7032", + } + +@misc{rfc7033, + author="P. Jones and G. Salgueiro and M. Jones and J. Smarr", + title="{WebFinger}", + howpublished="RFC 7033 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7033", + pages="1--28", + year=2013, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7033.txt", + key="RFC 7033", + abstract={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.}, + keywords="WebFinger, JRD, JSON Resource Descriptor, service discovery, service discovery protocol, information discovery, information discovery protocol", + doi="10.17487/RFC7033", + } + +@misc{rfc7034, + author="D. Ross and T. Gondrom", + title="{HTTP Header Field X-Frame-Options}", + howpublished="RFC 7034 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7034", + pages="1--14", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7034.txt", + key="RFC 7034", + abstract={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.}, + keywords="frame-options, HTTP header, websec", + doi="10.17487/RFC7034", + } + +@misc{rfc7035, + author="M. Thomson and B. Rosen and D. Stanley and G. Bajko and A. Thomson", + title="{Relative Location Representation}", + howpublished="RFC 7035 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7035", + pages="1--39", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7035.txt", + key="RFC 7035", + abstract={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. 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.}, + keywords="Relative, location", + doi="10.17487/RFC7035", + } + +@misc{rfc7036, + author="R. Housley", + title="{Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group}", + howpublished="RFC 7036 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7036", + pages="1--7", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7036.txt", + key="RFC 7036", + abstract={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.}, + doi="10.17487/RFC7036", + } + +@misc{rfc7037, + author="L. Yeh and M. Boucadair", + title="{RADIUS Option for the DHCPv6 Relay Agent}", + howpublished="RFC 7037 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7037", + pages="1--10", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7037.txt", + key="RFC 7037", + abstract={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.}, + keywords="DHCPv6, RADIUS", + doi="10.17487/RFC7037", + } + +@misc{rfc7038, + author="R. Ogier", + title="{Use of OSPF-MDR in Single-Hop Broadcast Networks}", + howpublished="RFC 7038 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7038", + pages="1--7", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7038.txt", + key="RFC 7038", + abstract={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.}, + keywords="routing, mobile ad hoc network, MANET designated router, wireless, point-to-multipoint interface", + doi="10.17487/RFC7038", + } + +@misc{rfc7039, + author="J. Wu and J. Bi and M. Bagnulo and F. Baker and C. {Vogt (Ed.)}", + title="{Source Address Validation Improvement (SAVI) Framework}", + howpublished="RFC 7039 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7039", + pages="1--14", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7039.txt", + key="RFC 7039", + abstract={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.}, + keywords="anti-spoofing, BCP38, ingress filtering", + doi="10.17487/RFC7039", + } + +@misc{rfc7040, + author="Y. Cui and J. Wu and P. Wu and O. Vautrin and Y. Lee", + title="{Public IPv4-over-IPv6 Access Network}", + howpublished="RFC 7040 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7040", + pages="1--13", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7040.txt", + key="RFC 7040", + abstract={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.}, + keywords="Public 4over6, IPv4 over IPv6, Access Network, DHCPv4 over IPv6, IPv6 Tunnel, IPv6 Transition", + doi="10.17487/RFC7040", + } + +@misc{rfc7041, + author="F. {Balus (Ed.)} and A. {Sajassi (Ed.)} and N. {Bitar (Ed.)}", + title="{Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging}", + howpublished="RFC 7041 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7041", + pages="1--15", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7041.txt", + key="RFC 7041", + abstract={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. 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. This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while mainta ining the service provider fit of the initial model.}, + doi="10.17487/RFC7041", + } + +@misc{rfc7042, + author="D. {Eastlake 3rd} and J. Abley", + title="{IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters}", + howpublished="RFC 7042 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7042", + pages="1--27", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7042.txt", + key="RFC 7042", + abstract={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.}, + keywords="Ethernet, Ethertype, 802, OUI, EUI, LSAP", + doi="10.17487/RFC7042", + } + +@misc{rfc7043, + author="J. Abley", + title="{Resource Records for EUI-48 and EUI-64 Addresses in the DNS}", + howpublished="RFC 7043 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7043", + pages="1--8", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7043.txt", + key="RFC 7043", + abstract={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. This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS. 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.}, + keywords="IEEE, ethernet", + doi="10.17487/RFC7043", + } + +@misc{rfc7044, + author="M. Barnes and F. Audet and S. Schubert and J. van Elburg and C. Holmberg", + title="{An Extension to the Session Initiation Protocol (SIP) for Request History Information}", + howpublished="RFC 7044 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7044", + pages="1--36", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7044.txt", + key="RFC 7044", + abstract={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.}, + keywords="history-info, retarget, enhanced services, voicemail, automatic call distribution", + doi="10.17487/RFC7044", + } + +@misc{rfc7045, + author="B. Carpenter and S. Jiang", + title="{Transmission and Processing of IPv6 Extension Headers}", + howpublished="RFC 7045 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7045", + pages="1--10", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7045.txt", + key="RFC 7045", + abstract={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.}, + doi="10.17487/RFC7045", + } + +@misc{rfc7046, + author="M. Waehlisch and T. Schmidt and S. Venaas", + title="{A Common API for Transparent Hybrid Multicast}", + howpublished="RFC 7046 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7046", + pages="1--41", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7046.txt", + key="RFC 7046", + abstract={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.}, + keywords="Peer-to-Peer (P2P), adaptive multicast, multicast naming, multicast addressing", + doi="10.17487/RFC7046", + } + +@misc{rfc7047, + author="B. Pfaff and B. {Davie (Ed.)}", + title="{The Open vSwitch Database Management Protocol}", + howpublished="RFC 7047 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7047", + pages="1--35", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7047.txt", + key="RFC 7047", + abstract={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.}, + keywords="vswitch, virtualization, overlay, OVS", + doi="10.17487/RFC7047", + } + +@misc{rfc7048, + author="E. Nordmark and I. Gashinsky", + title="{Neighbor Unreachability Detection Is Too Impatient}", + howpublished="RFC 7048 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7048", + pages="1--8", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7048.txt", + key="RFC 7048", + abstract={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.}, + keywords="6MAN, IPv6, Neighbor Discovery", + doi="10.17487/RFC7048", + } + +@misc{rfc7049, + author="C. Bormann and P. Hoffman", + title="{Concise Binary Object Representation (CBOR)}", + howpublished="RFC 7049 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7049", + pages="1--54", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7049.txt", + key="RFC 7049", + abstract={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.}, + keywords="parser, encoder, binary format, data interchange format, JSON", + doi="10.17487/RFC7049", + } + +@misc{rfc7050, + author="T. Savolainen and J. Korhonen and D. Wing", + title="{Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis}", + howpublished="RFC 7050 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7050", + pages="1--22", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7050.txt", + key="RFC 7050", + abstract={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.}, + keywords="NAT64, DNS64, 464XLAT, Pref64::/n", + doi="10.17487/RFC7050", + } + +@misc{rfc7051, + author="J. {Korhonen (Ed.)} and T. {Savolainen (Ed.)}", + title="{Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix}", + howpublished="RFC 7051 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7051", + pages="1--25", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7051.txt", + key="RFC 7051", + abstract={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.}, + keywords="NAT64, DNS64, 464XLAT, Pref64::/n", + doi="10.17487/RFC7051", + } + +@misc{rfc7052, + author="G. Schudel and A. Jain and V. Moreno", + title="{Locator/ID Separation Protocol (LISP) MIB}", + howpublished="RFC 7052 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7052", + pages="1--66", + year=2013, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7052.txt", + key="RFC 7052", + abstract={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.}, + doi="10.17487/RFC7052", + } + +@misc{rfc7053, + author="M. Tuexen and I. Ruengeler and R. Stewart", + title="{SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol}", + howpublished="RFC 7053 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7053", + pages="1--8", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7053.txt", + key="RFC 7053", + abstract={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.}, + doi="10.17487/RFC7053", + } + +@misc{rfc7054, + author="A. Farrel and H. Endo and R. Winter and Y. Koike and M. Paul", + title="{Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)}", + howpublished="RFC 7054 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7054", + pages="1--11", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7054.txt", + key="RFC 7054", + abstract={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. 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.}, + doi="10.17487/RFC7054", + } + +@misc{rfc7055, + author="S. {Hartman (Ed.)} and J. Howlett", + title="{A GSS-API Mechanism for the Extensible Authentication Protocol}", + howpublished="RFC 7055 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7055", + pages="1--35", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7055.txt", + key="RFC 7055", + abstract={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.}, + doi="10.17487/RFC7055", + } + +@misc{rfc7056, + author="S. Hartman and J. Howlett", + title="{Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism}", + howpublished="RFC 7056 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7056", + pages="1--11", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7056.txt", + key="RFC 7056", + abstract={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.}, + doi="10.17487/RFC7056", + } + +@misc{rfc7057, + author="S. Winter and J. Salowey", + title="{Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)}", + howpublished="RFC 7057 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7057", + pages="1--7", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7057.txt", + key="RFC 7057", + abstract={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.}, + keywords="EAP, AAA", + doi="10.17487/RFC7057", + } + +@misc{rfc7058, + author="A. Amirante and T. Castaldi and L. Miniero and S P. Romano", + title="{Media Control Channel Framework (CFW) Call Flow Examples}", + howpublished="RFC 7058 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7058", + pages="1--182", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7058.txt", + key="RFC 7058", + abstract={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.}, + keywords="MediaCtrl, Media Server Control, Media Control Channel Framework", + doi="10.17487/RFC7058", + } + +@misc{rfc7059, + author="S. Steffann and I. van Beijnum and R. van Rein", + title="{A Comparison of IPv6-over-IPv4 Tunnel Mechanisms}", + howpublished="RFC 7059 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7059", + pages="1--41", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7059.txt", + key="RFC 7059", + abstract={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.}, + doi="10.17487/RFC7059", + } + +@misc{rfc7060, + author="M. Napierala and E. Rosen and IJ. Wijnands", + title="{Using LDP Multipoint Extensions on Targeted LDP Sessions}", + howpublished="RFC 7060 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7060", + pages="1--9", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7060.txt", + key="RFC 7060", + abstract={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.}, + doi="10.17487/RFC7060", + } + +@misc{rfc7061, + author="R. Sinnema and E. Wilde", + title="{eXtensible Access Control Markup Language (XACML) XML Media Type}", + howpublished="RFC 7061 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7061", + pages="1--8", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7061.txt", + key="RFC 7061", + abstract={This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).}, + doi="10.17487/RFC7061", + } + +@misc{rfc7062, + author="F. {Zhang (Ed.)} and D. Li and H. Li and S. Belotti and D. Ceccarelli", + title="{Framework for GMPLS and PCE Control of G.709 Optical Transport Networks}", + howpublished="RFC 7062 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7062", + pages="1--26", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7062.txt", + key="RFC 7062", + abstract={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.}, + doi="10.17487/RFC7062", + } + +@misc{rfc7063, + author="L. Zheng and J. Zhang and R. Parekh", + title="{Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments}", + howpublished="RFC 7063 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7063", + pages="1--12", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7063.txt", + key="RFC 7063", + abstract={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.}, + doi="10.17487/RFC7063", + } + +@misc{rfc7064, + author="S. Nandakumar and G. Salgueiro and P. Jones and M. Petit-Huguenin", + title="{URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol}", + howpublished="RFC 7064 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7064", + pages="1--9", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7064.txt", + key="RFC 7064", + abstract={This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.}, + doi="10.17487/RFC7064", + } + +@misc{rfc7065, + author="M. Petit-Huguenin and S. Nandakumar and G. Salgueiro and P. Jones", + title="{Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers}", + howpublished="RFC 7065 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7065", + pages="1--9", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7065.txt", + key="RFC 7065", + abstract={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).}, + doi="10.17487/RFC7065", + } + +@misc{rfc7066, + author="J. {Korhonen (Ed.)} and J. {Arkko (Ed.)} and T. Savolainen and S. Krishnan", + title="{IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts}", + howpublished="RFC 7066 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7066", + pages="1--20", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7066.txt", + key="RFC 7066", + abstract={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.}, + doi="10.17487/RFC7066", + } + +@misc{rfc7067, + author="L. Dunbar and D. {Eastlake 3rd} and R. Perlman and I. Gashinsky", + title="{Directory Assistance Problem and High-Level Design Proposal}", + howpublished="RFC 7067 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7067", + pages="1--15", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7067.txt", + key="RFC 7067", + abstract={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\&Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus. 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.}, + keywords="TRILL, Orchestration, Directory, Push, Pull, RBridge, ARP", + doi="10.17487/RFC7067", + } + +@misc{rfc7068, + author="E. McMurry and B. Campbell", + title="{Diameter Overload Control Requirements}", + howpublished="RFC 7068 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7068", + pages="1--29", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7068.txt", + key="RFC 7068", + abstract={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.}, + doi="10.17487/RFC7068", + } + +@misc{rfc7069, + author="R. Alimi and A. Rahman and D. Kutscher and Y. Yang and H. Song and K. Pentikousis", + title="{DECoupled Application Data Enroute (DECADE)}", + howpublished="RFC 7069 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7069", + pages="1--35", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7069.txt", + key="RFC 7069", + abstract={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.}, + keywords="decade", + doi="10.17487/RFC7069", + } + +@misc{rfc7070, + author="N. Borenstein and M. Kucherawy", + title="{An Architecture for Reputation Reporting}", + howpublished="RFC 7070 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7070", + pages="1--14", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7070.txt", + key="RFC 7070", + abstract={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.}, + keywords="domain, security, messaging, dkim, spf, authentication, reputation", + doi="10.17487/RFC7070", + } + +@misc{rfc7071, + author="N. Borenstein and M. Kucherawy", + title="{A Media Type for Reputation Interchange}", + howpublished="RFC 7071 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7071", + pages="1--17", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7071.txt", + key="RFC 7071", + abstract={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.}, + keywords="reputation, domain, security, messaging, dkim, spf, authentication", + doi="10.17487/RFC7071", + } + +@misc{rfc7072, + author="N. Borenstein and M. Kucherawy", + title="{A Reputation Query Protocol}", + howpublished="RFC 7072 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7072", + pages="1--9", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7072.txt", + key="RFC 7072", + abstract={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.}, + keywords="reputation, domain, security, messaging, dkim, spf, authentication", + doi="10.17487/RFC7072", + } + +@misc{rfc7073, + author="N. Borenstein and M. Kucherawy", + title="{A Reputation Response Set for Email Identifiers}", + howpublished="RFC 7073 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7073", + pages="1--8", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7073.txt", + key="RFC 7073", + abstract={This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.}, + keywords="reputation, domain, security, messaging, dkim, spf, authentication", + doi="10.17487/RFC7073", + } + +@misc{rfc7074, + author="L. Berger and J. Meuric", + title="{Revised Definition of the GMPLS Switching Capability and Type Fields}", + howpublished="RFC 7074 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7074", + pages="1--9", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7074.txt", + key="RFC 7074", + abstract={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.}, + doi="10.17487/RFC7074", + } + +@misc{rfc7075, + author="T. Tsou and R. Hao and T. {Taylor (Ed.)}", + title="{Realm-Based Redirection In Diameter}", + howpublished="RFC 7075 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7075", + pages="1--10", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7075.txt", + key="RFC 7075", + abstract={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''. 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).}, + keywords="Diameter, routing", + doi="10.17487/RFC7075", + } + +@misc{rfc7076, + author="M. Joseph and J. Susoy", + title="{P6R's Secure Shell Public Key Subsystem}", + howpublished="RFC 7076 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7076", + pages="1--11", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7076.txt", + key="RFC 7076", + abstract={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. 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)). 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). Rights to manage keys and certifica tes 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.}, + keywords="key management, certificate management, security", + doi="10.17487/RFC7076", + } + +@misc{rfc7077, + author="S. Krishnan and S. Gundavelli and M. Liebsch and H. Yokota and J. Korhonen", + title="{Update Notifications for Proxy Mobile IPv6}", + howpublished="RFC 7077 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7077", + pages="1--21", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7077.txt", + key="RFC 7077", + abstract={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.}, + keywords="MIPv6", + doi="10.17487/RFC7077", + } + +@misc{rfc7078, + author="A. Matsumoto and T. Fujisaki and T. Chown", + title="{Distributing Address Selection Policy Using DHCPv6}", + howpublished="RFC 7078 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7078", + pages="1--12", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7078.txt", + key="RFC 7078", + abstract={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.}, + doi="10.17487/RFC7078", + } + +@misc{rfc7079, + author="N. Del {Regno (Ed.)} and A. {Malis (Ed.)}", + title="{The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results}", + howpublished="RFC 7079 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7079", + pages="1--41", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7079.txt", + key="RFC 7079", + abstract={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.}, + keywords="Control Word (CW), Control Channel (CC)", + doi="10.17487/RFC7079", + } + +@misc{rfc7080, + author="A. Sajassi and S. Salam and N. Bitar and F. Balus", + title="{Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges}", + howpublished="RFC 7080 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7080", + pages="1--26", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7080.txt", + key="RFC 7080", + abstract={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 functio nality can be incorporated into H-VPLS with existing MPLS access.}, + keywords="h-vpls", + doi="10.17487/RFC7080", + } + +@misc{rfc7081, + author="E. Ivov and P. Saint-Andre and E. Marocco", + title="{CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 7081 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7081", + pages="1--19", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7081.txt", + key="RFC 7081", + abstract={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.}, + keywords="real-time communication, unified communication, voice, video, instant messaging, chat, presence, telephony", + doi="10.17487/RFC7081", + } + +@misc{rfc7082, + author="R. Shekh-Yusef and M. Barnes", + title="{Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)}", + howpublished="RFC 7082 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7082", + pages="1--10", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7082.txt", + key="RFC 7082", + abstract={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. 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 <service-uris> element in the SIP conferencing event package.}, + doi="10.17487/RFC7082", + } + +@misc{rfc7083, + author="R. Droms", + title="{Modification to Default Values of SOL\_MAX\_RT and INF\_MAX\_RT}", + howpublished="RFC 7083 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7083", + pages="1--7", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7083.txt", + key="RFC 7083", + abstract={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.}, + doi="10.17487/RFC7083", + } + +@misc{rfc7084, + author="H. Singh and W. Beebee and C. Donley and B. Stark", + title="{Basic Requirements for IPv6 Customer Edge Routers}", + howpublished="RFC 7084 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7084", + pages="1--21", + year=2013, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7084.txt", + key="RFC 7084", + abstract={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.}, + keywords="6rd, DS-Lite", + doi="10.17487/RFC7084", + } + +@misc{rfc7085, + author="J. Levine and P. Hoffman", + title="{Top-Level Domains That Are Already Dotless}", + howpublished="RFC 7085 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7085", + pages="1--6", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7085.txt", + key="RFC 7085", + abstract={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.}, + keywords="DNS", + doi="10.17487/RFC7085", + } + +@misc{rfc7086, + author="A. Keranen and G. Camarillo and J. Maenpaa", + title="{Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)}", + howpublished="RFC 7086 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7086", + pages="1--10", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7086.txt", + key="RFC 7086", + abstract={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.}, + keywords="HIP, overlay, P2P", + doi="10.17487/RFC7086", + } + +@misc{rfc7087, + author="H. van {Helvoort (Ed.)} and L. {Andersson (Ed.)} and N. {Sprecher (Ed.)}", + 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}", + howpublished="RFC 7087 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7087", + pages="1--21", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7087.txt", + key="RFC 7087", + abstract={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. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations. 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.}, + doi="10.17487/RFC7087", + } + +@misc{rfc7088, + author="D. Worley", + title="{Session Initiation Protocol Service Example -- Music on Hold}", + howpublished="RFC 7088 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7088", + pages="1--36", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7088.txt", + key="RFC 7088", + abstract={``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.}, + keywords="Music on hold", + doi="10.17487/RFC7088", + } + +@misc{rfc7089, + author="H. Van de Sompel and M. Nelson and R. Sanderson", + title="{HTTP Framework for Time-Based Access to Resource States -- Memento}", + howpublished="RFC 7089 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7089", + pages="1--50", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7089.txt", + key="RFC 7089", + abstract={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.}, + keywords="HTTP, content negotiation, datetime negotiation, resource versions, archival resources, Memento", + doi="10.17487/RFC7089", + } + +@misc{rfc7090, + author="H. Schulzrinne and H. Tschofenig and C. Holmberg and M. Patel", + title="{Public Safety Answering Point (PSAP) Callback}", + howpublished="RFC 7090 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7090", + pages="1--18", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7090.txt", + key="RFC 7090", + abstract={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. 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 d ocument 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.}, + keywords="PSAP, callback, SIP, emergency, VoIP", + doi="10.17487/RFC7090", + } + +@misc{rfc7091, + author="V. {Dolmatov (Ed.)} and A. Degtyarev", + title="{GOST R 34.10-2012: Digital Signature Algorithm}", + howpublished="RFC 7091 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7091", + pages="1--21", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7091.txt", + key="RFC 7091", + abstract={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.}, + doi="10.17487/RFC7091", + } + +@misc{rfc7092, + author="H. Kaplan and V. Pascual", + title="{A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents}", + howpublished="RFC 7092 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7092", + pages="1--10", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7092.txt", + key="RFC 7092", + abstract={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). 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.}, + keywords="SIP, B2BUA, taxonomy", + doi="10.17487/RFC7092", + } + +@misc{rfc7093, + author="S. Turner and S. Kent and J. Manger", + title="{Additional Methods for Generating Key Identifiers Values}", + howpublished="RFC 7093 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7093", + pages="1--5", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7093.txt", + key="RFC 7093", + abstract={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.}, + doi="10.17487/RFC7093", + } + +@misc{rfc7094, + author="D. McPherson and D. Oran and D. Thaler and E. Osterweil", + title="{Architectural Considerations of IP Anycast}", + howpublished="RFC 7094 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7094", + pages="1--22", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7094.txt", + key="RFC 7094", + abstract={This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.}, + keywords="anycast, architecture", + doi="10.17487/RFC7094", + } + +@misc{rfc7095, + author="P. Kewisch", + title="{jCard: The JSON Format for vCard}", + howpublished="RFC 7095 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7095", + pages="1--29", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7095.txt", + key="RFC 7095", + abstract={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.}, + keywords="jCard, JSON, vCard, addressbook, contacts, CardDAV, PIM", + doi="10.17487/RFC7095", + } + +@misc{rfc7096, + author="S. {Belotti (Ed.)} and P. Grandi and D. {Ceccarelli (Ed.)} and D. Caviglia and F. Zhang and D. Li", + title="{Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)}", + howpublished="RFC 7096 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7096", + pages="1--23", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7096.txt", + key="RFC 7096", + abstract={ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.}, + keywords="Routing, CCAMP Working Group, OSPF, GMPLS, G709, OTN", + doi="10.17487/RFC7096", + } + +@misc{rfc7097, + author="J. Ott and V. {Singh (Ed.)} and I. Curcio", + title="{RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets}", + howpublished="RFC 7097 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7097", + pages="1--11", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7097.txt", + key="RFC 7097", + abstract={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.}, + keywords="RTP, RTCP, discard metrics", + doi="10.17487/RFC7097", + } + +@misc{rfc7098, + author="B. Carpenter and S. Jiang and W. Tarreau", + title="{Using the IPv6 Flow Label for Load Balancing in Server Farms}", + howpublished="RFC 7098 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7098", + pages="1--13", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7098.txt", + key="RFC 7098", + abstract={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.}, + keywords="ECMP", + doi="10.17487/RFC7098", + } + +@misc{rfc7100, + author="P. Resnick", + title="{Retirement of the ``Internet Official Protocol Standards'' Summary Document}", + howpublished="RFC 7100 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7100", + pages="1--3", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7100.txt", + key="RFC 7100", + abstract={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.}, + doi="10.17487/RFC7100", + } + +@misc{rfc7101, + author="S. Ginoza", + title="{List of Internet Official Protocol Standards: Replaced by a Web Page}", + howpublished="RFC 7101 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7101", + pages="1--4", + year=2013, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7101.txt", + key="RFC 7101", + abstract={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.}, + doi="10.17487/RFC7101", + } + +@misc{rfc7102, + author="JP. Vasseur", + title="{Terms Used in Routing for Low-Power and Lossy Networks}", + howpublished="RFC 7102 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7102", + pages="1--8", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7102.txt", + key="RFC 7102", + abstract={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.}, + doi="10.17487/RFC7102", + } + +@misc{rfc7103, + author="M. Kucherawy and G. Shapiro and N. Freed", + title="{Advice for Safe Handling of Malformed Messages}", + howpublished="RFC 7103 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7103", + pages="1--24", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7103.txt", + key="RFC 7103", + abstract={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.}, + keywords="MTA, SMTP", + doi="10.17487/RFC7103", + } + +@misc{rfc7104, + author="A. Begen and Y. Cai and H. Ou", + title="{Duplication Grouping Semantics in the Session Description Protocol}", + howpublished="RFC 7104 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7104", + pages="1--10", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7104.txt", + key="RFC 7104", + abstract={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.}, + keywords="SDP, ssrc, synchronization source, grouping framework", + doi="10.17487/RFC7104", + } + +@misc{rfc7105, + author="M. Thomson and J. Winterbottom", + title="{Using Device-Provided Location-Related Measurements in Location Configuration Protocols}", + howpublished="RFC 7105 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7105", + pages="1--74", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7105.txt", + key="RFC 7105", + abstract={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.}, + keywords="HELD, Location, Measurements, Device-based", + doi="10.17487/RFC7105", + } + +@misc{rfc7106, + author="E. Ivov", + title="{A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State}", + howpublished="RFC 7106 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7106", + pages="1--6", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7106.txt", + key="RFC 7106", + abstract={This document defines and registers a value of ``grouptextchat'' (``Group Text Chat'') for the URI <purpose> element of SIP's Conference Event Package.}, + keywords="SIP, Conference Event Package, service-uris, conference-uris, URI purpose", + doi="10.17487/RFC7106", + } + +@misc{rfc7107, + author="R. Housley", + title="{Object Identifier Registry for the S/MIME Mail Security Working Group}", + howpublished="RFC 7107 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7107", + pages="1--18", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7107.txt", + key="RFC 7107", + abstract={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.}, + doi="10.17487/RFC7107", + } + +@misc{rfc7108, + author="J. Abley and T. Manderson", + title="{A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes}", + howpublished="RFC 7108 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7108", + pages="1--11", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7108.txt", + key="RFC 7108", + abstract={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. 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. 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.}, + doi="10.17487/RFC7108", + } + +@misc{rfc7109, + author="H. Yokota and D. Kim and B. Sarikaya and F. Xia", + title="{Flow Bindings Initiated by Home Agents for Mobile IPv6}", + howpublished="RFC 7109 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7109", + pages="1--18", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7109.txt", + key="RFC 7109", + abstract={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.}, + keywords="MIPv6, Flow mobility", + doi="10.17487/RFC7109", + } + +@misc{rfc7110, + author="M. Chen and W. Cao and S. Ning and F. Jounay and S. Delord", + title="{Return Path Specified Label Switched Path (LSP) Ping}", + howpublished="RFC 7110 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7110", + pages="1--21", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7737", +url="https://www.rfc-editor.org/rfc/rfc7110.txt", + key="RFC 7110", + abstract={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.}, + keywords="Tunnel Stack, Reply TC", + doi="10.17487/RFC7110", + } + +@misc{rfc7111, + author="M. Hausenblas and E. Wilde and J. Tennison", + title="{URI Fragment Identifiers for the text/csv Media Type}", + howpublished="RFC 7111 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7111", + pages="1--13", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7111.txt", + key="RFC 7111", + abstract={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.}, + keywords="mime", + doi="10.17487/RFC7111", + } + +@misc{rfc7112, + author="F. Gont and V. Manral and R. Bonica", + title="{Implications of Oversized IPv6 Header Chains}", + howpublished="RFC 7112 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7112", + pages="1--8", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7112.txt", + key="RFC 7112", + abstract={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.}, + doi="10.17487/RFC7112", + } + +@misc{rfc7113, + author="F. Gont", + title="{Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)}", + howpublished="RFC 7113 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7113", + pages="1--13", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7113.txt", + key="RFC 7113", + abstract={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.}, + doi="10.17487/RFC7113", + } + +@misc{rfc7114, + author="B. Leiba", + title="{Creation of a Registry for smime-type Parameter Values}", + howpublished="RFC 7114 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7114", + pages="1--4", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7114.txt", + key="RFC 7114", + abstract={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.}, + doi="10.17487/RFC7114", + } + +@misc{rfc7115, + author="R. Bush", + title="{Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 7115 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7115", + pages="1--11", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7115.txt", + key="RFC 7115", + abstract={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.}, + doi="10.17487/RFC7115", + } + +@misc{rfc7116, + author="K. Scott and M. Blanchet", + title="{Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries}", + howpublished="RFC 7116 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7116", + pages="1--10", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7116.txt", + key="RFC 7116", + abstract={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.}, + doi="10.17487/RFC7116", + } + +@misc{rfc7117, + author="R. {Aggarwal (Ed.)} and Y. Kamite and L. Fang and Y. Rekhter and C. Kodeboniya", + title="{Multicast in Virtual Private LAN Service (VPLS)}", + howpublished="RFC 7117 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7117", + pages="1--50", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7117.txt", + key="RFC 7117", + abstract={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. 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 V PLS instances.}, + doi="10.17487/RFC7117", + } + +@misc{rfc7118, + author="I. Baz Castillo and J. Millan Villegas and V. Pascual", + title="{The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)}", + howpublished="RFC 7118 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7118", + pages="1--25", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7118.txt", + key="RFC 7118", + abstract={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.}, + keywords="SIP, WebSocket", + doi="10.17487/RFC7118", + } + +@misc{rfc7119, + author="B. Claise and A. Kobayashi and B. Trammell", + title="{Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators}", + howpublished="RFC 7119 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7119", + pages="1--32", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7119.txt", + key="RFC 7119", + abstract={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.}, + doi="10.17487/RFC7119", + } + +@misc{rfc7120, + author="M. Cotton", + title="{Early IANA Allocation of Standards Track Code Points}", + howpublished="RFC 7120 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7120", + pages="1--9", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7120.txt", + key="RFC 7120", + abstract={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.}, + keywords="early allocation, policy, protocol", + doi="10.17487/RFC7120", + } + +@misc{rfc7121, + author="K. Ogawa and W. Wang and E. Haleplidis and J. Hadi Salim", + title="{High Availability within a Forwarding and Control Element Separation (ForCES) Network Element}", + howpublished="RFC 7121 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7121", + pages="1--31", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7391", +url="https://www.rfc-editor.org/rfc/rfc7121.txt", + key="RFC 7121", + abstract={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.}, + keywords="ForCES, HA", + doi="10.17487/RFC7121", + } + +@misc{rfc7122, + author="H. Kruse and S. Jero and S. Ostermann", + title="{Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)}", + howpublished="RFC 7122 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7122", + pages="1--11", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7122.txt", + key="RFC 7122", + abstract={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.}, + doi="10.17487/RFC7122", + } + +@misc{rfc7123, + author="F. Gont and W. Liu", + title="{Security Implications of IPv6 on IPv4 Networks}", + howpublished="RFC 7123 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7123", + pages="1--19", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7123.txt", + key="RFC 7123", + abstract={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.}, + doi="10.17487/RFC7123", + } + +@misc{rfc7124, + author="E. Beili", + title="{Ethernet in the First Mile Copper (EFMCu) Interfaces MIB}", + howpublished="RFC 7124 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7124", + pages="1--6", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7124.txt", + key="RFC 7124", + abstract={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.}, + keywords="EFM-CU-MIB, ieee", + doi="10.17487/RFC7124", + } + +@misc{rfc7125, + author="B. Trammell and P. Aitken", + title="{Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element}", + howpublished="RFC 7125 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7125", + pages="1--6", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7125.txt", + key="RFC 7125", + abstract={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.}, + doi="10.17487/RFC7125", + } + +@misc{rfc7126, + author="F. Gont and R. Atkinson and C. Pignataro", + title="{Recommendations on Filtering of IPv4 Packets Containing IPv4 Options}", + howpublished="RFC 7126 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7126", + pages="1--36", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7126.txt", + key="RFC 7126", + abstract={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.}, + doi="10.17487/RFC7126", + } + +@misc{rfc7127, + author="O. Kolkman and S. Bradner and S. Turner", + title="{Characterization of Proposed Standards}", + howpublished="RFC 7127 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7127", + pages="1--5", + year=2014, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7127.txt", + key="RFC 7127", + abstract={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.}, + keywords="Guidance, Standards, Standards Process, Advancement, Proposed Standard", + doi="10.17487/RFC7127", + } + +@misc{rfc7128, + author="R. Bush and R. Austein and K. Patel and H. Gredler and M. Waehlisch", + title="{Resource Public Key Infrastructure (RPKI) Router Implementation Report}", + howpublished="RFC 7128 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7128", + pages="1--11", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7128.txt", + key="RFC 7128", + abstract={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.}, + keywords="routing, security", + doi="10.17487/RFC7128", + } + +@misc{rfc7129, + author="R. Gieben and W. Mekking", + title="{Authenticated Denial of Existence in the DNS}", + howpublished="RFC 7129 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7129", + pages="1--30", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7129.txt", + key="RFC 7129", + abstract={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. 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.}, + keywords="Internet, DNSSEC, Denial of Existence, NSEC, NSEC3", + doi="10.17487/RFC7129", + } + +@misc{rfc7130, + author="M. {Bhatia (Ed.)} and M. {Chen (Ed.)} and S. {Boutros (Ed.)} and M. {Binderberger (Ed.)} and J. {Haas (Ed.)}", + title="{Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces}", + howpublished="RFC 7130 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7130", + pages="1--11", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7130.txt", + key="RFC 7130", + abstract={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. 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.}, + doi="10.17487/RFC7130", + } + +@misc{rfc7131, + author="M. Barnes and F. Audet and S. Schubert and H. van Elburg and C. Holmberg", + title="{Session Initiation Protocol (SIP) History-Info Header Call Flow Examples}", + howpublished="RFC 7131 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7131", + pages="1--52", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7131.txt", + key="RFC 7131", + abstract={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.}, + keywords="SIP, History-Info, RFC4244bis, Example, Call Flow", + doi="10.17487/RFC7131", + } + +@misc{rfc7132, + author="S. Kent and A. Chi", + title="{Threat Model for BGP Path Security}", + howpublished="RFC 7132 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7132", + pages="1--20", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7132.txt", + key="RFC 7132", + abstract={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. 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.}, + keywords="BGPSEC, RPKI, SIDR", + doi="10.17487/RFC7132", + } + +@misc{rfc7133, + author="S. Kashima and A. {Kobayashi (Ed.)} and P. Aitken", + title="{Information Elements for Data Link Layer Traffic Measurement}", + howpublished="RFC 7133 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7133", + pages="1--41", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7133.txt", + key="RFC 7133", + abstract={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.}, + keywords="IPFIX, PSAMP, Provider Bridge, Provider Backbone Bridge, ipfix", + doi="10.17487/RFC7133", + } + +@misc{rfc7134, + author="B. Rosen", + title="{The Management Policy of the Resource Priority Header (RPH) Registry Changed to ``IETF Review''}", + howpublished="RFC 7134 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7134", + pages="1--2", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7134.txt", + key="RFC 7134", + abstract={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''.}, + keywords="Resource-Priority Namespaces, Resource-Priority Priority-values", + doi="10.17487/RFC7134", + } + +@misc{rfc7135, + author="J. Polk", + title="{Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications}", + howpublished="RFC 7135 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7135", + pages="1--9", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7135.txt", + key="RFC 7135", + abstract={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.}, + doi="10.17487/RFC7135", + } + +@misc{rfc7136, + author="B. Carpenter and S. Jiang", + title="{Significance of IPv6 Interface Identifiers}", + howpublished="RFC 7136 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7136", + pages="1--10", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7136.txt", + key="RFC 7136", + abstract={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.}, + doi="10.17487/RFC7136", + } + +@misc{rfc7137, + author="A. Retana and S. Ratliff", + title="{Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks}", + howpublished="RFC 7137 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7137", + pages="1--8", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7137.txt", + key="RFC 7137", + abstract={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. This document updates RFC 5820.}, + doi="10.17487/RFC7137", + } + +@misc{rfc7138, + author="D. {Ceccarelli (Ed.)} and F. Zhang and S. Belotti and R. Rao and J. Drake", + title="{Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks}", + howpublished="RFC 7138 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7138", + pages="1--36", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7138.txt", + key="RFC 7138", + abstract={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.}, + keywords="OSPF, GMPLS, G709, OTN", + doi="10.17487/RFC7138", + } + +@misc{rfc7139, + author="F. {Zhang (Ed.)} and G. Zhang and S. Belotti and D. Ceccarelli and K. Pithewan", + title="{GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks}", + howpublished="RFC 7139 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7139", + pages="1--27", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7892", +url="https://www.rfc-editor.org/rfc/rfc7139.txt", + key="RFC 7139", + abstract={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. 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.}, + doi="10.17487/RFC7139", + } + +@misc{rfc7140, + author="L. Jin and F. Jounay and IJ. Wijnands and N. Leymann", + title="{LDP Extensions for Hub and Spoke Multipoint Label Switched Path}", + howpublished="RFC 7140 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7140", + pages="1--15", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7358", +url="https://www.rfc-editor.org/rfc/rfc7140.txt", + key="RFC 7140", + abstract={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.}, + keywords="P2MP LSP, MP2MP LSP", + doi="10.17487/RFC7140", + } + +@misc{rfc7141, + author="B. Briscoe and J. Manner", + title="{Byte and Packet Congestion Notification}", + howpublished="RFC 7141 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7141", + pages="1--41", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7141.txt", + key="RFC 7141", + abstract={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.}, + keywords="active queue management, aqm, availability, denial of service, dos, quality of service, qos, congestion control, fairness, incentives, architecture layering, protocol", + doi="10.17487/RFC7141", + } + +@misc{rfc7142, + author="M. Shand and L. Ginsberg", + title="{Reclassification of RFC 1142 to Historic}", + howpublished="RFC 7142 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7142", + pages="1--3", + year=2014, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7142.txt", + key="RFC 7142", + abstract={This memo reclassifies RFC 1142, ``OSI IS-IS Intra-domain Routing Protocol'', to Historic status. This memo also obsoletes RFC 1142.}, + doi="10.17487/RFC7142", + } + +@misc{rfc7143, + author="M. Chadalapaka and J. Satran and K. Meth and D. Black", + title="{Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)}", + howpublished="RFC 7143 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7143", + pages="1--295", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7143.txt", + key="RFC 7143", + abstract={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. 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.}, + keywords="iSCSI, SCSI, storage, SAN, block storage, SCSI object storage devices, OSD, SAM, disk, T10", + doi="10.17487/RFC7143", + } + +@misc{rfc7144, + author="F. Knight and M. Chadalapaka", + title="{Internet Small Computer System Interface (iSCSI) SCSI Features Update}", + howpublished="RFC 7144 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7144", + pages="1--25", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7144.txt", + key="RFC 7144", + abstract={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.}, + doi="10.17487/RFC7144", + } + +@misc{rfc7145, + author="M. Ko and A. Nezhinsky", + title="{Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification}", + howpublished="RFC 7145 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7145", + pages="1--91", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7145.txt", + key="RFC 7145", + abstract={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. This document obsoletes RFC 5046.}, + doi="10.17487/RFC7145", + } + +@misc{rfc7146, + author="D. Black and P. Koning", + title="{Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3}", + howpublished="RFC 7146 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7146", + pages="1--18", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7146.txt", + key="RFC 7146", + abstract={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.}, + keywords="IPsec", + doi="10.17487/RFC7146", + } + +@misc{rfc7147, + author="M. Bakke and P. Venkatesen", + title="{Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI)}", + howpublished="RFC 7147 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7147", + pages="1--92", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7147.txt", + key="RFC 7147", + abstract={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). This document obsoletes RFC 4544.}, + keywords="ISCSI-MIB", + doi="10.17487/RFC7147", + } + +@misc{rfc7148, + author="X. Zhou and J. Korhonen and C. Williams and S. Gundavelli and CJ. Bernardos", + title="{Prefix Delegation Support for Proxy Mobile IPv6}", + howpublished="RFC 7148 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7148", + pages="1--27", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7148.txt", + key="RFC 7148", + abstract={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.}, + keywords="Prefix Delegation, Proxy Mobile IPv6, PMIPv6, Mobile Router", + doi="10.17487/RFC7148", + } + +@misc{rfc7149, + author="M. Boucadair and C. Jacquenet", + title="{Software-Defined Networking: A Perspective from within a Service Provider Environment}", + howpublished="RFC 7149 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7149", + pages="1--20", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7149.txt", + key="RFC 7149", + abstract={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. 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.}, + keywords="Network Automation, Policy Management, Connectivity Provisioning, Service Parameter Exposure, Dynamic Negotiation, Dynamic Service Provisioning, Autonomic, Programmable Networks", + doi="10.17487/RFC7149", + } + +@misc{rfc7150, + author="F. Zhang and A. Farrel", + title="{Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol}", + howpublished="RFC 7150 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7150", + pages="1--12", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7470", +url="https://www.rfc-editor.org/rfc/rfc7150.txt", + key="RFC 7150", + abstract={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. 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.}, + doi="10.17487/RFC7150", + } + +@misc{rfc7151, + author="P. Hethmon and R. McMurray", + title="{File Transfer Protocol HOST Command for Virtual Hosts}", + howpublished="RFC 7151 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7151", + pages="1--24", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7151.txt", + key="RFC 7151", + abstract={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.}, + keywords="FTP, HOST", + doi="10.17487/RFC7151", + } + +@misc{rfc7152, + author="R. {Key (Ed.)} and S. DeLord and F. Jounay and L. Huang and Z. Liu and M. Paul", + title="{Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)}", + howpublished="RFC 7152 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7152", + pages="1--12", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7152.txt", + key="RFC 7152", + abstract={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.}, + keywords="RMP, Rooted-Multipoint, VPLS, Virtual Private LAN Service, E-VPN, Ethernet Virtual Private Network, MPLS, Multi-Protocol Label Switching, CE, Carrier Ethernet", + doi="10.17487/RFC7152", + } + +@misc{rfc7153, + author="E. Rosen and Y. Rekhter", + title="{IANA Registries for BGP Extended Communities}", + howpublished="RFC 7153 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7153", + pages="1--16", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7153.txt", + key="RFC 7153", + abstract={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.}, + keywords="Border Gateway Protocol", + doi="10.17487/RFC7153", + } + +@misc{rfc7154, + author="S. {Moonesamy (Ed.)}", + title="{IETF Guidelines for Conduct}", + howpublished="RFC 7154 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7154", + pages="1--7", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7154.txt", + key="RFC 7154", + abstract={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. This document is an updated version of the guidelines for conduct originally published in RFC 3184.}, + doi="10.17487/RFC7154", + } + +@misc{rfc7155, + author="G. {Zorn (Ed.)}", + title="{Diameter Network Access Server Application}", + howpublished="RFC 7155 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7155", + pages="1--70", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7155.txt", + key="RFC 7155", + abstract={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.}, + keywords="AAA, Authentication, Authorization, Accounting, Remote Access", + doi="10.17487/RFC7155", + } + +@misc{rfc7156, + author="G. Zorn and Q. Wu and J. Korhonen", + title="{Diameter Support for Proxy Mobile IPv6 Localized Routing}", + howpublished="RFC 7156 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7156", + pages="1--11", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7156.txt", + key="RFC 7156", + abstract={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.}, + doi="10.17487/RFC7156", + } + +@misc{rfc7157, + author="O. {Troan (Ed.)} and D. Miles and S. Matsushima and T. Okimoto and D. Wing", + title="{IPv6 Multihoming without Network Address Translation}", + howpublished="RFC 7157 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7157", + pages="1--22", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7157.txt", + key="RFC 7157", + abstract={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.}, + keywords="NPTv6", + doi="10.17487/RFC7157", + } + +@misc{rfc7158, + author="T. {Bray (Ed.)}", + title="{The JavaScript Object Notation (JSON) Data Interchange Format}", + howpublished="RFC 7158 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7158", + pages="1--16", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7159", +url="https://www.rfc-editor.org/rfc/rfc7158.txt", + key="RFC 7158", + abstract={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 document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.}, + doi="10.17487/RFC7158", + } + +@misc{rfc7159, + author="T. {Bray (Ed.)}", + title="{The JavaScript Object Notation (JSON) Data Interchange Format}", + howpublished="RFC 7159 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7159", + pages="1--16", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8259", +url="https://www.rfc-editor.org/rfc/rfc7159.txt", + key="RFC 7159", + abstract={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 document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.}, + doi="10.17487/RFC7159", + } + +@misc{rfc7160, + author="M. Petit-Huguenin and G. {Zorn (Ed.)}", + title="{Support for Multiple Clock Rates in an RTP Session}", + howpublished="RFC 7160 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7160", + pages="1--13", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7160.txt", + key="RFC 7160", + abstract={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.}, + doi="10.17487/RFC7160", + } + +@misc{rfc7161, + author="LM. Contreras and CJ. Bernardos and I. Soto", + title="{Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)}", + howpublished="RFC 7161 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7161", + pages="1--37", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7161.txt", + key="RFC 7161", + abstract={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).}, + keywords="PMIPv6, Proxy Mobile IPv6, multicast, handover, SIAL", + doi="10.17487/RFC7161", + } + +@misc{rfc7162, + author="A. Melnikov and D. Cridland", + title="{IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)}", + howpublished="RFC 7162 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7162", + pages="1--52", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7162.txt", + key="RFC 7162", + abstract={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. 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. 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. Finally, this document also upda tes the line-length recommendation in Section 3.2.1.5 of RFC 2683.}, + keywords="IMAP, CONDSTORE, QRESYNC, VANISHED, EXPUNGE, quick resynchronization", + doi="10.17487/RFC7162", + } + +@misc{rfc7163, + author="C. Holmberg and I. Sedlacek", + title="{URN for Country-Specific Emergency Services}", + howpublished="RFC 7163 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7163", + pages="1--4", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7163.txt", + key="RFC 7163", + abstract={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.}, + keywords="sip, emergency, urn, country, 5031, sos", + doi="10.17487/RFC7163", + } + +@misc{rfc7164, + author="K. Gross and R. Brandenburg", + title="{RTP and Leap Seconds}", + howpublished="RFC 7164 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7164", + pages="1--9", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7164.txt", + key="RFC 7164", + abstract={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.}, + keywords="Leap second, rtp, Real-time Transport Protocol, ntp, Network Time Protocol, UTC, Universal Coordinated Time, tai, International Atomic Time, Unix time", + doi="10.17487/RFC7164", + } + +@misc{rfc7165, + author="R. Barnes", + title="{Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)}", + howpublished="RFC 7165 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7165", + pages="1--25", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7165.txt", + key="RFC 7165", + abstract={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.}, + keywords="JWS, JWE, JWK, JWA, JWT, CMS, S/MIME, JOSE, XMPP, ALTO, OAuth", + doi="10.17487/RFC7165", + } + +@misc{rfc7166, + author="M. Bhatia and V. Manral and A. Lindem", + title="{Supporting Authentication Trailer for OSPFv3}", + howpublished="RFC 7166 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7166", + pages="1--23", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7166.txt", + key="RFC 7166", + abstract={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. 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.}, + doi="10.17487/RFC7166", + } + +@misc{rfc7167, + author="D. Frost and S. Bryant and M. Bocci and L. Berger", + title="{A Framework for Point-to-Multipoint MPLS in Transport Networks}", + howpublished="RFC 7167 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7167", + pages="1--12", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7167.txt", + key="RFC 7167", + abstract={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.}, + keywords="mpls-tp, mpls", + doi="10.17487/RFC7167", + } + +@misc{rfc7168, + author="I. Nazar", + title="{The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)}", + howpublished="RFC 7168 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7168", + pages="1--7", + year=2014, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7168.txt", + key="RFC 7168", + abstract={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.}, + doi="10.17487/RFC7168", + } + +@misc{rfc7169, + author="S. Turner", + title="{The NSA (No Secrecy Afforded) Certificate Extension}", + howpublished="RFC 7169 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7169", + pages="1--3", + year=2014, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7169.txt", + key="RFC 7169", + abstract={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.}, + doi="10.17487/RFC7169", + } + +@misc{rfc7170, + author="H. Zhou and N. Cam-Winget and J. Salowey and S. Hanna", + title="{Tunnel Extensible Authentication Protocol (TEAP) Version 1}", + howpublished="RFC 7170 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7170", + pages="1--101", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7170.txt", + key="RFC 7170", + abstract={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.}, + keywords="EAP, Tunnel", + doi="10.17487/RFC7170", + } + +@misc{rfc7171, + author="N. Cam-Winget and P. Sangster", + title="{PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods}", + howpublished="RFC 7171 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7171", + pages="1--19", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7171.txt", + key="RFC 7171", + abstract={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.}, + keywords="NEA EAP", + doi="10.17487/RFC7171", + } + +@misc{rfc7172, + author="D. {Eastlake 3rd} and M. Zhang and P. Agarwal and R. Perlman and D. Dutt", + title="{Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling}", + howpublished="RFC 7172 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7172", + pages="1--27", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7172.txt", + key="RFC 7172", + abstract={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.}, + keywords="TRILL, VLAN, Fine-Grained, Label", + doi="10.17487/RFC7172", + } + +@misc{rfc7173, + author="L. Yong and D. {Eastlake 3rd} and S. Aldrin and J. Hudson", + title="{Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires}", + howpublished="RFC 7173 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7173", + pages="1--11", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7173.txt", + key="RFC 7173", + abstract={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.}, + keywords="TRILL, pseudowires, MPLS, RBridge", + doi="10.17487/RFC7173", + } + +@misc{rfc7174, + author="S. Salam and T. Senevirathne and S. Aldrin and D. {Eastlake 3rd}", + title="{Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework}", + howpublished="RFC 7174 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7174", + pages="1--33", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7174.txt", + key="RFC 7174", + abstract={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.}, + keywords="RBridge, CFM, BFD, MEP, MIP, MA, Fault, Performance, Maintenance, Continuity, Connectivity, Delay, Operations, Administration", + doi="10.17487/RFC7174", + } + +@misc{rfc7175, + author="V. Manral and D. {Eastlake 3rd} and D. Ward and A. Banerjee", + title="{Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support}", + howpublished="RFC 7175 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7175", + pages="1--12", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7175.txt", + key="RFC 7175", + abstract={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. 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.}, + keywords="RBridge, Echo, one-hop", + doi="10.17487/RFC7175", + } + +@misc{rfc7176, + author="D. {Eastlake 3rd} and T. Senevirathne and A. Ghanwani and D. Dutt and A. Banerjee", + title="{Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS}", + howpublished="RFC 7176 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7176", + pages="1--45", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7176.txt", + key="RFC 7176", + abstract={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.}, + keywords="Affinity, multicast, multi-topology, fine-grained, VLAN", + doi="10.17487/RFC7176", + } + +@misc{rfc7177, + author="D. {Eastlake 3rd} and R. Perlman and A. Ghanwani and H. Yang and V. Manral", + title="{Transparent Interconnection of Lots of Links (TRILL): Adjacency}", + howpublished="RFC 7177 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7177", + pages="1--35", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7780, 8139, 8249, 8377", +url="https://www.rfc-editor.org/rfc/rfc7177.txt", + key="RFC 7177", + abstract={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.}, + keywords="RBridge, TRILL, Adjacency, BFD, p2p, point-to-point", + doi="10.17487/RFC7177", + } + +@misc{rfc7178, + author="D. {Eastlake 3rd} and V. Manral and Y. Li and S. Aldrin and D. Ward", + title="{Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support}", + howpublished="RFC 7178 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7178", + pages="1--21", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7978", +url="https://www.rfc-editor.org/rfc/rfc7178.txt", + key="RFC 7178", + abstract={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.}, + keywords="TRILL, native", + doi="10.17487/RFC7178", + } + +@misc{rfc7179, + author="D. {Eastlake 3rd} and A. Ghanwani and V. Manral and Y. Li and C. Bestler", + title="{Transparent Interconnection of Lots of Links (TRILL): Header Extension}", + howpublished="RFC 7179 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7179", + pages="1--12", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7780", +url="https://www.rfc-editor.org/rfc/rfc7179.txt", + key="RFC 7179", + abstract={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.}, + keywords="RBridge, extension, option", + doi="10.17487/RFC7179", + } + +@misc{rfc7180, + author="D. {Eastlake 3rd} and M. Zhang and A. Ghanwani and V. Manral and A. Banerjee", + title="{Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates}", + howpublished="RFC 7180 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7180", + pages="1--24", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7780", +url="https://www.rfc-editor.org/rfc/rfc7180.txt", + key="RFC 7180", + abstract={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. 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.}, + keywords="TRILL, RBridge, IS-IS, reachability, overload, MTU, DEI, multicast", + doi="10.17487/RFC7180", + } + +@misc{rfc7181, + author="T. Clausen and C. Dearlove and P. Jacquet and U. Herberg", + title="{The Optimized Link State Routing Protocol Version 2}", + howpublished="RFC 7181 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7181", + pages="1--115", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7183, 7187, 7188, 7466", +url="https://www.rfc-editor.org/rfc/rfc7181.txt", + key="RFC 7181", + abstract={This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).}, + keywords="MANET, ad hoc network, NHDP", + doi="10.17487/RFC7181", + } + +@misc{rfc7182, + author="U. Herberg and T. Clausen and C. Dearlove", + title="{Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)}", + howpublished="RFC 7182 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7182", + pages="1--31", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7182.txt", + key="RFC 7182", + abstract={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.}, + keywords="NHDP, OLSRv2, security, integrity, routing", + doi="10.17487/RFC7182", + } + +@misc{rfc7183, + author="U. Herberg and C. Dearlove and T. Clausen", + title="{Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)}", + howpublished="RFC 7183 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7183", + pages="1--15", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7183.txt", + key="RFC 7183", + abstract={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. The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444. This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.}, + keywords="MANET, OLSRv2, Security, Integrity protection, ICV", + doi="10.17487/RFC7183", + } + +@misc{rfc7184, + author="U. Herberg and R. Cole and T. Clausen", + title="{Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2}", + howpublished="RFC 7184 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7184", + pages="1--86", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7184.txt", + key="RFC 7184", + abstract={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.}, + keywords="Network Management, Management Information Base, MIB, SMIv2, Routing, MANET, Optimized Link STate Routing Protocol version 2", + doi="10.17487/RFC7184", + } + +@misc{rfc7185, + author="C. Dearlove and T. Clausen and P. Jacquet", + title="{Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale}", + howpublished="RFC 7185 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7185", + pages="1--25", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7185.txt", + key="RFC 7185", + abstract={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.}, + keywords="MANET, ad hoc network, proactive, NHDP, neighborhood discovery, OLSR, OLSRv2, routing protocol, metrics", + doi="10.17487/RFC7185", + } + +@misc{rfc7186, + author="J. Yi and U. Herberg and T. Clausen", + title="{Security Threats for the Neighborhood Discovery Protocol (NHDP)}", + howpublished="RFC 7186 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7186", + pages="1--20", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7985", +url="https://www.rfc-editor.org/rfc/rfc7186.txt", + key="RFC 7186", + abstract={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.}, + doi="10.17487/RFC7186", + } + +@misc{rfc7187, + author="C. Dearlove and T. Clausen", + title="{Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)}", + howpublished="RFC 7187 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7187", + pages="1--5", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7187.txt", + key="RFC 7187", + abstract={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.}, + doi="10.17487/RFC7187", + } + +@misc{rfc7188, + author="C. Dearlove and T. Clausen", + title="{Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs}", + howpublished="RFC 7188 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7188", + pages="1--16", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7722", +url="https://www.rfc-editor.org/rfc/rfc7188.txt", + key="RFC 7188", + abstract={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).}, + keywords="MANET, OLSRv2, NHDP, TLV", + doi="10.17487/RFC7188", + } + +@misc{rfc7189, + author="G. Mirsky", + title="{Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP)}", + howpublished="RFC 7189 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7189", + pages="1--7", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7189.txt", + key="RFC 7189", + abstract={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.}, + keywords="PW VCCV, MPLS-TP CC/CV/RDI", + doi="10.17487/RFC7189", + } + +@misc{rfc7190, + author="C. Villamizar", + title="{Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)}", + howpublished="RFC 7190 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7190", + pages="1--15", + year=2014, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7190.txt", + key="RFC 7190", + abstract={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. 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.}, + keywords="MPLS, composite link, link aggregation, ECMP, link bundling, multipath, MPLS-TP", + doi="10.17487/RFC7190", + } + +@misc{rfc7191, + author="R. Housley", + title="{Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types}", + howpublished="RFC 7191 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7191", + pages="1--25", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7191.txt", + key="RFC 7191", + abstract={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.}, + doi="10.17487/RFC7191", + } + +@misc{rfc7192, + author="S. Turner", + title="{Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types}", + howpublished="RFC 7192 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7192", + pages="1--6", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7192.txt", + key="RFC 7192", + abstract={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.}, + keywords="Key Package, Key Package Receipt, Key Package Error", + doi="10.17487/RFC7192", + } + +@misc{rfc7193, + author="S. Turner and R. Housley and J. Schaad", + title="{The application/cms Media Type}", + howpublished="RFC 7193 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7193", + pages="1--12", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7193.txt", + key="RFC 7193", + abstract={This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.}, + keywords="Cryptographic Message Syntax", + doi="10.17487/RFC7193", + } + +@misc{rfc7194, + author="R. Hartmann", + title="{Default Port for Internet Relay Chat (IRC) via TLS/SSL}", + howpublished="RFC 7194 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7194", + pages="1--6", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7194.txt", + key="RFC 7194", + abstract={This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.}, + doi="10.17487/RFC7194", + } + +@misc{rfc7195, + author="M. Garcia-Martin and S. Veikkolainen", + title="{Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)}", + howpublished="RFC 7195 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7195", + pages="1--39", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7195.txt", + key="RFC 7195", + abstract={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).}, + keywords="PSTN", + doi="10.17487/RFC7195", + } + +@misc{rfc7196, + author="C. Pelsser and R. Bush and K. Patel and P. Mohapatra and O. Maennel", + title="{Making Route Flap Damping Usable}", + howpublished="RFC 7196 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7196", + pages="1--8", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7196.txt", + key="RFC 7196", + abstract={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.}, + keywords="rfd", + doi="10.17487/RFC7196", + } + +@misc{rfc7197, + author="A. Begen and Y. Cai and H. Ou", + title="{Duplication Delay Attribute in the Session Description Protocol}", + howpublished="RFC 7197 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7197", + pages="1--11", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7197.txt", + key="RFC 7197", + abstract={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.}, + keywords="Interleaving, temporal diversity, temporal redundancy, time shifted, delayed duplication", + doi="10.17487/RFC7197", + } + +@misc{rfc7198, + author="A. Begen and C. Perkins", + title="{Duplicating RTP Streams}", + howpublished="RFC 7198 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7198", + pages="1--13", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7198.txt", + key="RFC 7198", + abstract={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.}, + keywords="RTP duplication, live/live, redundancy", + doi="10.17487/RFC7198", + } + +@misc{rfc7199, + author="R. Barnes and M. Thomson and J. Winterbottom and H. Tschofenig", + title="{Location Configuration Extensions for Policy Management}", + howpublished="RFC 7199 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7199", + pages="1--20", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7199.txt", + key="RFC 7199", + abstract={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.}, + keywords="geopriv, geolocation, privacy, policy", + doi="10.17487/RFC7199", + } + +@misc{rfc7200, + author="C. Shen and H. Schulzrinne and A. Koike", + title="{A Session Initiation Protocol (SIP) Load-Control Event Package}", + howpublished="RFC 7200 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7200", + pages="1--44", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7200.txt", + key="RFC 7200", + abstract={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.}, + keywords="SIP, Overload Control, Server, Performance", + doi="10.17487/RFC7200", + } + +@misc{rfc7201, + author="M. Westerlund and C. Perkins", + title="{Options for Securing RTP Sessions}", + howpublished="RFC 7201 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7201", + pages="1--37", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7201.txt", + key="RFC 7201", + abstract={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.}, + keywords="Secure RTP, SRTP, key management, real-time, media", + doi="10.17487/RFC7201", + } + +@misc{rfc7202, + author="C. Perkins and M. Westerlund", + title="{Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution}", + howpublished="RFC 7202 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7202", + pages="1--10", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7202.txt", + key="RFC 7202", + abstract={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.}, + keywords="SRTP, RTP Profile, Payload Format", + doi="10.17487/RFC7202", + } + +@misc{rfc7203, + author="T. Takahashi and K. Landfield and Y. Kadobayashi", + title="{An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information}", + howpublished="RFC 7203 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7203", + pages="1--28", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7203.txt", + key="RFC 7203", + abstract={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.}, + keywords="data structure, information architecture, incident response, response team, security incident, information exchange, knowledge sharing, security operation, automation, vulnerability, CERT, CSIRT", + doi="10.17487/RFC7203", + } + +@misc{rfc7204, + author="T. Haynes", + title="{Requirements for Labeled NFS}", + howpublished="RFC 7204 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7204", + pages="1--18", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7204.txt", + key="RFC 7204", + abstract={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.}, + keywords="NFSv4", + doi="10.17487/RFC7204", + } + +@misc{rfc7205, + author="A. Romanow and S. Botzko and M. Duckworth and R. {Even (Ed.)}", + title="{Use Cases for Telepresence Multistreams}", + howpublished="RFC 7205 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7205", + pages="1--17", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7205.txt", + key="RFC 7205", + abstract={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.}, + doi="10.17487/RFC7205", + } + +@misc{rfc7206, + author="P. Jones and G. Salgueiro and J. Polk and L. Liess and H. Kaplan", + title="{Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks}", + howpublished="RFC 7206 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7206", + pages="1--15", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7206.txt", + key="RFC 7206", + abstract={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.}, + doi="10.17487/RFC7206", + } + +@misc{rfc7207, + author="M. Ortseifen and G. Dickfeld", + title="{A Uniform Resource Name (URN) Namespace for Eurosystem Messaging}", + howpublished="RFC 7207 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7207", + pages="1--8", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7207.txt", + key="RFC 7207", + abstract={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).}, + keywords="URN Namespace, Eurosystem, TARGET2, TARGET2-Securities, ESCB", + doi="10.17487/RFC7207", + } + +@misc{rfc7208, + author="S. Kitterman", + title="{Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1}", + howpublished="RFC 7208 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7208", + pages="1--64", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7372", +url="https://www.rfc-editor.org/rfc/rfc7208.txt", + key="RFC 7208", + abstract={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. This document obsoletes RFC 4408.}, + keywords="spoofing, spf, anti-forgery, authentication", + doi="10.17487/RFC7208", + } + +@misc{rfc7209, + author="A. Sajassi and R. Aggarwal and J. Uttaro and N. Bitar and W. Henderickx and A. Isaac", + title="{Requirements for Ethernet VPN (EVPN)}", + howpublished="RFC 7209 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7209", + pages="1--15", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7209.txt", + key="RFC 7209", + abstract={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.}, + keywords="ethernet l2vpn", + doi="10.17487/RFC7209", + } + +@misc{rfc7210, + author="R. Housley and T. Polk and S. Hartman and D. Zhang", + title="{Database of Long-Lived Symmetric Cryptographic Keys}", + howpublished="RFC 7210 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7210", + pages="1--14", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7210.txt", + key="RFC 7210", + abstract={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.}, + doi="10.17487/RFC7210", + } + +@misc{rfc7211, + author="S. Hartman and D. Zhang", + title="{Operations Model for Router Keying}", + howpublished="RFC 7211 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7211", + pages="1--18", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7211.txt", + key="RFC 7211", + abstract={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.}, + doi="10.17487/RFC7211", + } + +@misc{rfc7212, + author="D. Frost and S. Bryant and M. Bocci", + title="{MPLS Generic Associated Channel (G-ACh) Advertisement Protocol}", + howpublished="RFC 7212 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7212", + pages="1--23", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7212.txt", + key="RFC 7212", + abstract={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.}, + doi="10.17487/RFC7212", + } + +@misc{rfc7213, + author="D. Frost and S. Bryant and M. Bocci", + title="{MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing}", + howpublished="RFC 7213 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7213", + pages="1--9", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7213.txt", + key="RFC 7213", + abstract={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.}, + keywords="MPLS", + doi="10.17487/RFC7213", + } + +@misc{rfc7214, + author="L. Andersson and C. Pignataro", + title="{Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry}", + howpublished="RFC 7214 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7214", + pages="1--7", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7214.txt", + key="RFC 7214", + abstract={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. This document also updates RFCs 6374, 6378, 6427, and 6428.}, + doi="10.17487/RFC7214", + } + +@misc{rfc7215, + author="L. Jakab and A. Cabellos-Aparicio and F. Coras and J. Domingo-Pascual and D. Lewis", + title="{Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations}", + howpublished="RFC 7215 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7215", + pages="1--30", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7215.txt", + key="RFC 7215", + abstract={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.}, + keywords="LISP, deployment", + doi="10.17487/RFC7215", + } + +@misc{rfc7216, + author="M. Thomson and R. Bellis", + title="{Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS}", + howpublished="RFC 7216 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7216", + pages="1--18", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7216.txt", + key="RFC 7216", + abstract={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. 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.}, + keywords="HELD, LIS, Discovery, NAT, Residential Gateway", + doi="10.17487/RFC7216", + } + +@misc{rfc7217, + author="F. Gont", + title="{A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)}", + howpublished="RFC 7217 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7217", + pages="1--19", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7217.txt", + key="RFC 7217", + abstract={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).}, + doi="10.17487/RFC7217", + } + +@misc{rfc7218, + author="O. Gudmundsson", + title="{Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)}", + howpublished="RFC 7218 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7218", + pages="1--5", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7218.txt", + key="RFC 7218", + abstract={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.}, + keywords="DNSSEC, DANE, Applications", + doi="10.17487/RFC7218", + } + +@misc{rfc7219, + author="M. Bagnulo and A. Garcia-Martinez", + title="{SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)}", + howpublished="RFC 7219 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7219", + pages="1--38", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7219.txt", + key="RFC 7219", + abstract={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.}, + keywords="IPv6, ingress filtering, packet filtering, Neighbor Discovery", + doi="10.17487/RFC7219", + } + +@misc{rfc7220, + author="M. Boucadair and R. Penno and D. Wing", + title="{Description Option for the Port Control Protocol (PCP)}", + howpublished="RFC 7220 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7220", + pages="1--6", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7220.txt", + key="RFC 7220", + abstract={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.}, + doi="10.17487/RFC7220", + } + +@misc{rfc7221, + author="A. Farrel and D. {Crocker (Ed.)}", + title="{Handling of Internet-Drafts by IETF Working Groups}", + howpublished="RFC 7221 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7221", + pages="1--14", + year=2014, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7221.txt", + key="RFC 7221", + abstract={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.}, + keywords="IETF, process, working group, Internet-Draft, adoption, handling, creation", + doi="10.17487/RFC7221", + } + +@misc{rfc7222, + author="M. Liebsch and P. Seite and H. Yokota and J. Korhonen and S. Gundavelli", + title="{Quality-of-Service Option for Proxy Mobile IPv6}", + howpublished="RFC 7222 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7222", + pages="1--58", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7222.txt", + key="RFC 7222", + abstract={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.}, + keywords="QoS, Quality of Service, PMIP-QoS, PMIPv6-QoS, WiFi-QoS, 3GPP-QoS", + doi="10.17487/RFC7222", + } + +@misc{rfc7223, + author="M. Bjorklund", + title="{A YANG Data Model for Interface Management}", + howpublished="RFC 7223 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7223", + pages="1--39", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8343", +url="https://www.rfc-editor.org/rfc/rfc7223.txt", + key="RFC 7223", + abstract={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).}, + keywords="NETCONF, ietf-interfaces", + doi="10.17487/RFC7223", + } + +@misc{rfc7224, + author="M. Bjorklund", + title="{IANA Interface Type YANG Module}", + howpublished="RFC 7224 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7224", + pages="1--37", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7224.txt", + key="RFC 7224", + abstract={This document defines the initial version of the iana-if-type YANG module.}, + keywords="yang, netconf, iana-if-type", + doi="10.17487/RFC7224", + } + +@misc{rfc7225, + author="M. Boucadair", + title="{Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)}", + howpublished="RFC 7225 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7225", + pages="1--17", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7225.txt", + key="RFC 7225", + abstract={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.}, + doi="10.17487/RFC7225", + } + +@misc{rfc7226, + author="C. {Villamizar (Ed.)} and D. {McDysan (Ed.)} and S. Ning and A. Malis and L. Yong", + title="{Requirements for Advanced Multipath in MPLS Networks}", + howpublished="RFC 7226 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7226", + pages="1--17", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7226.txt", + key="RFC 7226", + abstract={This document provides a set of requirements for Advanced Multipath in MPLS networks. 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.}, + keywords="MPLS, Advanced Multipath, composite link, link aggregation, ECMP, link bundling, delay metric", + doi="10.17487/RFC7226", + } + +@misc{rfc7227, + author="D. Hankins and T. Mrugalski and M. Siodelski and S. Jiang and S. Krishnan", + title="{Guidelines for Creating New DHCPv6 Options}", + howpublished="RFC 7227 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7227", + pages="1--35", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7227.txt", + key="RFC 7227", + abstract={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.}, + keywords="DHCPv6, option guidelines, option guidance, option format", + doi="10.17487/RFC7227", + } + +@misc{rfc7228, + author="C. Bormann and M. Ersue and A. Keranen", + title="{Terminology for Constrained-Node Networks}", + howpublished="RFC 7228 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7228", + pages="1--17", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7228.txt", + key="RFC 7228", + abstract={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.}, + keywords="IoT, Internet of Things, Embedded Internet, Smart Object, Sensor Network, WSN, Constrained node, Constrained network, LLN, LoWPAN, 6LoWPAN, Always-on, Low-power, Energy efficient", + doi="10.17487/RFC7228", + } + +@misc{rfc7229, + author="R. Housley", + title="{Object Identifiers for Test Certificate Policies}", + howpublished="RFC 7229 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7229", + pages="1--4", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7229.txt", + key="RFC 7229", + abstract={This document provides several certificate policy identifiers for testing certificate handling software.}, + doi="10.17487/RFC7229", + } + +@misc{rfc7230, + author="R. {Fielding (Ed.)} and J. {Reschke (Ed.)}", + title="{Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing}", + howpublished="RFC 7230 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7230", + pages="1--89", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7230.txt", + key="RFC 7230", + abstract={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.}, + keywords="Hyptertext Transfer Protocol, HTTP, HTTP message format", + doi="10.17487/RFC7230", + } + +@misc{rfc7231, + author="R. {Fielding (Ed.)} and J. {Reschke (Ed.)}", + title="{Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content}", + howpublished="RFC 7231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7231", + pages="1--101", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7231.txt", + key="RFC 7231", + abstract={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.}, + keywords="Hypertext Transfer Protocol, HTTP, HTTP semantics, HTTP payload, HTTP content, HTTP method, HTTP status code", + doi="10.17487/RFC7231", + } + +@misc{rfc7232, + author="R. {Fielding (Ed.)} and J. {Reschke (Ed.)}", + title="{Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests}", + howpublished="RFC 7232 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7232", + pages="1--28", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7232.txt", + key="RFC 7232", + abstract={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.}, + keywords="HyperText Transfer Protocol, HTTP, HTTP conditional requests", + doi="10.17487/RFC7232", + } + +@misc{rfc7233, + author="R. {Fielding (Ed.)} and Y. {Lafon (Ed.)} and J. {Reschke (Ed.)}", + title="{Hypertext Transfer Protocol (HTTP/1.1): Range Requests}", + howpublished="RFC 7233 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7233", + pages="1--25", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7233.txt", + key="RFC 7233", + abstract={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.}, + doi="10.17487/RFC7233", + } + +@misc{rfc7234, + author="R. {Fielding (Ed.)} and M. {Nottingham (Ed.)} and J. {Reschke (Ed.)}", + title="{Hypertext Transfer Protocol (HTTP/1.1): Caching}", + howpublished="RFC 7234 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7234", + pages="1--43", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7234.txt", + key="RFC 7234", + abstract={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.}, + keywords="HTTP caching, HyperText Transfer Protocol, HTTP", + doi="10.17487/RFC7234", + } + +@misc{rfc7235, + author="R. {Fielding (Ed.)} and J. {Reschke (Ed.)}", + title="{Hypertext Transfer Protocol (HTTP/1.1): Authentication}", + howpublished="RFC 7235 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7235", + pages="1--19", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7235.txt", + key="RFC 7235", + abstract={The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.}, + keywords="HTTP authentication, HyperText Transfer Protocol, HTTP", + doi="10.17487/RFC7235", + } + +@misc{rfc7236, + author="J. Reschke", + title="{Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations}", + howpublished="RFC 7236 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7236", + pages="1--3", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7236.txt", + key="RFC 7236", + abstract={This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.}, + keywords="HyperText Transfer Protocol, HTTP, Authentication, Authentication Scheme", + doi="10.17487/RFC7236", + } + +@misc{rfc7237, + author="J. Reschke", + title="{Initial Hypertext Transfer Protocol (HTTP) Method Registrations}", + howpublished="RFC 7237 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7237", + pages="1--5", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7237.txt", + key="RFC 7237", + abstract={This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.}, + keywords="HyperText Transfer Protocol, HTTP, Request Method", + doi="10.17487/RFC7237", + } + +@misc{rfc7238, + author="J. Reschke", + title="{The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)}", + howpublished="RFC 7238 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7238", + pages="1--6", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7538", +url="https://www.rfc-editor.org/rfc/rfc7238.txt", + key="RFC 7238", + abstract={This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).}, + keywords="HTTP, redirect, status code", + doi="10.17487/RFC7238", + } + +@misc{rfc7239, + author="A. Petersson and M. Nilsson", + title="{Forwarded HTTP Extension}", + howpublished="RFC 7239 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7239", + pages="1--16", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7239.txt", + key="RFC 7239", + abstract={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. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.}, + keywords="proxy, x-forwarded-for, x-forwarded-by, x-forwarded-host, x-forwarded-proto, via", + doi="10.17487/RFC7239", + } + +@misc{rfc7240, + author="J. Snell", + title="{Prefer Header for HTTP}", + howpublished="RFC 7240 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7240", + pages="1--17", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8144", +url="https://www.rfc-editor.org/rfc/rfc7240.txt", + key="RFC 7240", + abstract={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.}, + keywords="http, prefer", + doi="10.17487/RFC7240", + } + +@misc{rfc7241, + author="S. Dawkins and P. Thaler and D. Romascanu and B. {Aboba (Ed.)}", + title="{The IEEE 802/IETF Relationship}", + howpublished="RFC 7241 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7241", + pages="1--35", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7241.txt", + key="RFC 7241", + abstract={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. 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.}, + keywords="snmp, aaa, simple network management protocol, authentication, authorization, accounting", + doi="10.17487/RFC7241", + } + +@misc{rfc7242, + author="M. Demmer and J. Ott and S. Perreault", + title="{Delay-Tolerant Networking TCP Convergence-Layer Protocol}", + howpublished="RFC 7242 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7242", + pages="1--22", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7242.txt", + key="RFC 7242", + abstract={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).}, + doi="10.17487/RFC7242", + } + +@misc{rfc7243, + author="V. {Singh (Ed.)} and J. Ott and I. Curcio", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric}", + howpublished="RFC 7243 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7243", + pages="1--12", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7243.txt", + key="RFC 7243", + abstract={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.}, + keywords="rtp, reception statistics, de-jitter buffer", + doi="10.17487/RFC7243", + } + +@misc{rfc7244, + author="H. Asaeda and Q. Wu and R. Huang", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting}", + howpublished="RFC 7244 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7244", + pages="1--13", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7244.txt", + key="RFC 7244", + abstract={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.}, + doi="10.17487/RFC7244", + } + +@misc{rfc7245, + author="A. {Hutton (Ed.)} and L. {Portman (Ed.)} and R. Jain and K. Rehor", + title="{An Architecture for Media Recording Using the Session Initiation Protocol}", + howpublished="RFC 7245 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7245", + pages="1--16", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7245.txt", + key="RFC 7245", + abstract={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).}, + keywords="sip", + doi="10.17487/RFC7245", + } + +@misc{rfc7246, + author="IJ. {Wijnands (Ed.)} and P. Hitchen and N. Leymann and W. Henderickx and A. Gulko and J. Tantsura", + title="{Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context}", + howpublished="RFC 7246 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7246", + pages="1--13", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7438", +url="https://www.rfc-editor.org/rfc/rfc7246.txt", + key="RFC 7246", + abstract={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 docum ent is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.}, + doi="10.17487/RFC7246", + } + +@misc{rfc7247, + author="P. Saint-Andre and A. Houri and J. Hildebrand", + title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling}", + howpublished="RFC 7247 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7247", + pages="1--24", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7247.txt", + key="RFC 7247", + abstract={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.}, + keywords="XMPP, SIP", + doi="10.17487/RFC7247", + } + +@misc{rfc7248, + author="P. Saint-Andre and A. Houri and J. Hildebrand", + title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence}", + howpublished="RFC 7248 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7248", + pages="1--30", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8048", +url="https://www.rfc-editor.org/rfc/rfc7248.txt", + key="RFC 7248", + abstract={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).}, + keywords="XMPP, Jabber, SIP, SIMPLE, IM, Instant Messaging, Presence", + doi="10.17487/RFC7248", + } + +@misc{rfc7249, + author="R. Housley", + title="{Internet Numbers Registries}", + howpublished="RFC 7249 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7249", + pages="1--6", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7249.txt", + key="RFC 7249", + abstract={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. This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.}, + doi="10.17487/RFC7249", + } + +@misc{rfc7250, + author="P. {Wouters (Ed.)} and H. {Tschofenig (Ed.)} and J. Gilmore and S. Weiler and T. Kivinen", + title="{Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 7250 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7250", + pages="1--18", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7250.txt", + key="RFC 7250", + abstract={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.}, + keywords="TLS, DNSSEC, DANE, Raw Public Key", + doi="10.17487/RFC7250", + } + +@misc{rfc7251, + author="D. McGrew and D. Bailey and M. Campagna and R. Dugal", + title="{AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS}", + howpublished="RFC 7251 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7251", + pages="1--10", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7251.txt", + key="RFC 7251", + abstract={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.}, + doi="10.17487/RFC7251", + } + +@misc{rfc7252, + author="Z. Shelby and K. Hartke and C. Bormann", + title="{The Constrained Application Protocol (CoAP)}", + howpublished="RFC 7252 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7252", + pages="1--112", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7959", +url="https://www.rfc-editor.org/rfc/rfc7252.txt", + key="RFC 7252", + abstract={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. 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.}, + doi="10.17487/RFC7252", + } + +@misc{rfc7253, + author="T. Krovetz and P. Rogaway", + title="{The OCB Authenticated-Encryption Algorithm}", + howpublished="RFC 7253 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7253", + pages="1--19", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7253.txt", + key="RFC 7253", + abstract={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).}, + keywords="OCB, AEAD, authenticated-encryption", + doi="10.17487/RFC7253", + } + +@misc{rfc7254, + author="M. {Montemurro (Ed.)} and A. Allen and D. McDonald and P. Gosden", + title="{A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)}", + howpublished="RFC 7254 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7254", + pages="1--16", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7254.txt", + key="RFC 7254", + abstract={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.}, + keywords="GSM, UMTS, LTE, 3GPP, Mobile, identifier, instance ID", + doi="10.17487/RFC7254", + } + +@misc{rfc7255, + author="A. {Allen (Ed.)}", + title="{Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID}", + howpublished="RFC 7255 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7255", + pages="1--9", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7255.txt", + key="RFC 7255", + abstract={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.}, + keywords="GSM, UMTS, LTE, 3GPP, IMS, SIP, GRUU, Mobile, identifier, instance ID", + doi="10.17487/RFC7255", + } + +@misc{rfc7256, + author="F. Le Faucheur and R. Maglione and T. Taylor", + title="{Multicast Control Extensions for the Access Node Control Protocol (ANCP)}", + howpublished="RFC 7256 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7256", + pages="1--99", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7256.txt", + key="RFC 7256", + abstract={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: o multicast replication initiated by the Network Access Server (NAS); o conditional access and admission control with white and black lists; o conditional access and admission control with grey lists; o bandwidth delegation; and o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification. 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.}, + doi="10.17487/RFC7256", + } + +@misc{rfc7257, + author="T. {Nadeau (Ed.)} and A. Kiran {Koushik (Ed.)} and R. {Mediratta (Ed.)}", + title="{Virtual Private LAN Service (VPLS) Management Information Base}", + howpublished="RFC 7257 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7257", + pages="1--48", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7257.txt", + key="RFC 7257", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects 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).}, + doi="10.17487/RFC7257", + } + +@misc{rfc7258, + author="S. Farrell and H. Tschofenig", + title="{Pervasive Monitoring Is an Attack}", + howpublished="RFC 7258 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7258", + pages="1--6", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7258.txt", + key="RFC 7258", + abstract={Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.}, + keywords="pervasive monitoring", + doi="10.17487/RFC7258", + } + +@misc{rfc7259, + author="P. Saint-Andre", + title="{The Jabber-ID Header Field}", + howpublished="RFC 7259 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7259", + pages="1--7", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7259.txt", + key="RFC 7259", + abstract={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.}, + keywords="Jabber, XMPP, Extensible Messaging and Presence Protocol, email, netnews, message header field, IM, instant messaging", + doi="10.17487/RFC7259", + } + +@misc{rfc7260, + author="A. Takacs and D. Fedyk and J. He", + title="{GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration}", + howpublished="RFC 7260 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7260", + pages="1--24", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7260.txt", + key="RFC 7260", + abstract={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.}, + keywords="MPLS-TP, Transport Profile, GELS, Ethernet Label Switching, PBB-TE, connectivity monitoring, OAM configuration", + doi="10.17487/RFC7260", + } + +@misc{rfc7261, + author="M. Perumal and P. Ravindran", + title="{Offer/Answer Considerations for G723 Annex A and G729 Annex B}", + howpublished="RFC 7261 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7261", + pages="1--8", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7261.txt", + key="RFC 7261", + abstract={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.}, + keywords="offer, answer", + doi="10.17487/RFC7261", + } + +@misc{rfc7262, + author="A. Romanow and S. Botzko and M. Barnes", + title="{Requirements for Telepresence Multistreams}", + howpublished="RFC 7262 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7262", + pages="1--12", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7262.txt", + key="RFC 7262", + abstract={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.}, + doi="10.17487/RFC7262", + } + +@misc{rfc7263, + author="N. Zong and X. Jiang and R. Even and Y. Zhang", + title="{An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing}", + howpublished="RFC 7263 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7263", + pages="1--20", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7263.txt", + key="RFC 7263", + abstract={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.}, + keywords="P2P", + doi="10.17487/RFC7263", + } + +@misc{rfc7264, + author="N. Zong and X. Jiang and R. Even and Y. Zhang", + title="{An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing}", + howpublished="RFC 7264 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7264", + pages="1--15", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7264.txt", + key="RFC 7264", + abstract={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.}, + keywords="P2P", + doi="10.17487/RFC7264", + } + +@misc{rfc7265, + author="P. Kewisch and C. Daboo and M. Douglass", + title="{jCal: The JSON Format for iCalendar}", + howpublished="RFC 7265 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7265", + pages="1--31", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7529", +url="https://www.rfc-editor.org/rfc/rfc7265.txt", + key="RFC 7265", + abstract={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.}, + doi="10.17487/RFC7265", + } + +@misc{rfc7266, + author="A. Clark and Q. Wu and R. Schott and G. Zorn", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting}", + howpublished="RFC 7266 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7266", + pages="1--23", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7266.txt", + key="RFC 7266", + abstract={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.}, + doi="10.17487/RFC7266", + } + +@misc{rfc7267, + author="L. {Martini (Ed.)} and M. {Bocci (Ed.)} and F. {Balus (Ed.)}", + title="{Dynamic Placement of Multi-Segment Pseudowires}", + howpublished="RFC 7267 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7267", + pages="1--24", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7267.txt", + key="RFC 7267", + abstract={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.}, + keywords="pw, pw switching point pe sub-tlv", + doi="10.17487/RFC7267", + } + +@misc{rfc7268, + author="B. Aboba and J. Malinen and P. Congdon and J. Salowey and M. Jones", + title="{RADIUS Attributes for IEEE 802 Networks}", + howpublished="RFC 7268 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7268", + pages="1--29", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8044", +url="https://www.rfc-editor.org/rfc/rfc7268.txt", + key="RFC 7268", + abstract={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.}, + doi="10.17487/RFC7268", + } + +@misc{rfc7269, + author="G. Chen and Z. Cao and C. Xie and D. Binet", + title="{NAT64 Deployment Options and Experience}", + howpublished="RFC 7269 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7269", + pages="1--22", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7269.txt", + key="RFC 7269", + abstract={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.}, + doi="10.17487/RFC7269", + } + +@misc{rfc7270, + author="A. Yourtchenko and P. Aitken and B. Claise", + title="{Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)}", + howpublished="RFC 7270 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7270", + pages="1--21", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7270.txt", + key="RFC 7270", + abstract={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.}, + keywords="IPFIX", + doi="10.17487/RFC7270", + } + +@misc{rfc7271, + author="J. {Ryoo (Ed.)} and E. {Gray (Ed.)} and H. van Helvoort and A. D'Alessandro and T. Cheung and E. Osborne", + 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}", + howpublished="RFC 7271 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7271", + pages="1--40", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8234", +url="https://www.rfc-editor.org/rfc/rfc7271.txt", + key="RFC 7271", + abstract={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. 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. 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. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.}, + keywords="PSC mode, APS mode, capabilities, priority, non-revertive, MS-W support, SD support, EXER support", + doi="10.17487/RFC7271", + } + +@misc{rfc7272, + author="R. van Brandenburg and H. Stokking and O. van Deventer and F. Boronat and M. Montagud and K. Gross", + title="{Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)}", + howpublished="RFC 7272 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7272", + pages="1--23", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7272.txt", + key="RFC 7272", + abstract={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. 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.}, + keywords="Inter-Destination Media Synchronization, RTP Control Protocol, RTCP", + doi="10.17487/RFC7272", + } + +@misc{rfc7273, + author="A. Williams and K. Gross and R. van Brandenburg and H. Stokking", + title="{RTP Clock Source Signalling}", + howpublished="RFC 7273 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7273", + pages="1--30", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7273.txt", + key="RFC 7273", + abstract={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.}, + keywords="clock, source", + doi="10.17487/RFC7273", + } + +@misc{rfc7274, + author="K. Kompella and L. Andersson and A. Farrel", + title="{Allocating and Retiring Special-Purpose MPLS Labels}", + howpublished="RFC 7274 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7274", + pages="1--11", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7274.txt", + key="RFC 7274", + abstract={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. 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. 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. This document updates a number of previous RFCs that use the term ``reserved label''. Specifical ly, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.}, + doi="10.17487/RFC7274", + } + +@misc{rfc7275, + author="L. Martini and S. Salam and A. Sajassi and M. Bocci and S. Matsushima and T. Nadeau", + title="{Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy}", + howpublished="RFC 7275 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7275", + pages="1--83", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7275.txt", + key="RFC 7275", + abstract={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.}, + keywords="iccp", + doi="10.17487/RFC7275", + } + +@misc{rfc7276, + author="T. Mizrahi and N. Sprecher and E. Bellagamba and Y. Weingarten", + title="{An Overview of Operations, Administration, and Maintenance (OAM) Tools}", + howpublished="RFC 7276 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7276", + pages="1--53", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7276.txt", + key="RFC 7276", + abstract={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. 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. The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an i ndex 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.}, + doi="10.17487/RFC7276", + } + +@misc{rfc7277, + author="M. Bjorklund", + title="{A YANG Data Model for IP Management}", + howpublished="RFC 7277 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7277", + pages="1--30", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8344", +url="https://www.rfc-editor.org/rfc/rfc7277.txt", + key="RFC 7277", + abstract={This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data.}, + keywords="netmod", + doi="10.17487/RFC7277", + } + +@misc{rfc7278, + author="C. Byrne and D. Drown and A. Vizdal", + title="{Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link}", + howpublished="RFC 7278 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7278", + pages="1--10", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7278.txt", + key="RFC 7278", + abstract={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.}, + doi="10.17487/RFC7278", + } + +@misc{rfc7279, + author="M. Shore and C. Pignataro", + title="{An Acceptable Use Policy for New ICMP Types and Codes}", + howpublished="RFC 7279 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7279", + pages="1--10", + year=2014, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7279.txt", + key="RFC 7279", + abstract={In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use. 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.}, + keywords="icmp, icmpv4, icmpv6", + doi="10.17487/RFC7279", + } + +@misc{rfc7280, + author="G. Fairhurst", + title="{IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry}", + howpublished="RFC 7280 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7280", + pages="1--7", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7280.txt", + key="RFC 7280", + abstract={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.}, + keywords="ULE, IANA", + doi="10.17487/RFC7280", + } + +@misc{rfc7281, + author="A. Melnikov", + title="{Authentication-Results Registration for S/MIME Signature Verification}", + howpublished="RFC 7281 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7281", + pages="1--11", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7281.txt", + key="RFC 7281", + abstract={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.}, + keywords="Authentication-Results, S/MIME", + doi="10.17487/RFC7281", + } + +@misc{rfc7282, + author="P. Resnick", + title="{On Consensus and Humming in the IETF}", + howpublished="RFC 7282 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7282", + pages="1--19", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7282.txt", + key="RFC 7282", + abstract={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. 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 ar ound which the IETF can come to (at least rough) consensus.}, + keywords="accommodate, agree, agreement, appease, argue, argument, balloting, capitulated, capitulation, chair, choice, choose, coin, compromise, count, decide, decision, disagree, disagreement, hands, horse-trade, horse-trading, hum, issue, judge, judging, king, majority, member, minority, object, objection, objector, president, rough, unaddressed, vote, voting, working group", + doi="10.17487/RFC7282", + } + +@misc{rfc7283, + author="Y. Cui and Q. Sun and T. Lemon", + title="{Handling Unknown DHCPv6 Messages}", + howpublished="RFC 7283 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7283", + pages="1--7", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7283.txt", + key="RFC 7283", + abstract={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.}, + keywords="DHCPv6, Unknown Messages", + doi="10.17487/RFC7283", + } + +@misc{rfc7284, + author="M. Lanthaler", + title="{The Profile URI Registry}", + howpublished="RFC 7284 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7284", + pages="1--5", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7284.txt", + key="RFC 7284", + abstract={This document defines a registry for profile URIs to be used in specifications standardizing profiles.}, + keywords="profile, profiles, URI, registry", + doi="10.17487/RFC7284", + } + +@misc{rfc7285, + author="R. {Alimi (Ed.)} and R. {Penno (Ed.)} and Y. {Yang (Ed.)} and S. Kiesel and S. Previdi and W. Roome and S. Shalunov and R. Woundy", + title="{Application-Layer Traffic Optimization (ALTO) Protocol}", + howpublished="RFC 7285 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7285", + pages="1--91", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7285.txt", + key="RFC 7285", + abstract={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. 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. Addit ional services are built on top of the maps. 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.}, + keywords="ALTO Information Resources, Network Map, PID, Filtered Network Map, Cost Map, Endpoint Property Service, Endpoint Cost Service", + doi="10.17487/RFC7285", + } + +@misc{rfc7286, + author="S. Kiesel and M. Stiemerling and N. Schwan and M. Scharf and H. Song", + title="{Application-Layer Traffic Optimization (ALTO) Server Discovery}", + howpublished="RFC 7286 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7286", + pages="1--15", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7286.txt", + key="RFC 7286", + abstract={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. 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.}, + doi="10.17487/RFC7286", + } + +@misc{rfc7287, + author="T. {Schmidt (Ed.)} and S. Gao and H. Zhang and M. Waehlisch", + title="{Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains}", + howpublished="RFC 7287 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7287", + pages="1--28", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7287.txt", + key="RFC 7287", + abstract={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.}, + doi="10.17487/RFC7287", + } + +@misc{rfc7288, + author="D. Thaler", + title="{Reflections on Host Firewalls}", + howpublished="RFC 7288 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7288", + pages="1--13", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7288.txt", + key="RFC 7288", + abstract={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.}, + keywords="Filter, Filtering", + doi="10.17487/RFC7288", + } + +@misc{rfc7289, + author="V. {Kuarsingh (Ed.)} and J. Cianfarani", + title="{Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs}", + howpublished="RFC 7289 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7289", + pages="1--20", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7289.txt", + key="RFC 7289", + abstract={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, he lping ease the CGN's impact on the network. This document does not intend to defend the merits of CGN.}, + keywords="NAT444, LSN, Large-Scale NAT", + doi="10.17487/RFC7289", + } + +@misc{rfc7290, + author="L. Ciavattone and R. Geib and A. Morton and M. Wieser", + title="{Test Plan and Results for Advancing RFC 2680 on the Standards Track}", + howpublished="RFC 7290 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7290", + pages="1--31", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7290.txt", + key="RFC 7290", + abstract={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.}, + keywords="packet loss, IPPM implementation comparison, perfas+, netem, IPPM comparison, metric test, WIPM, NetProbe", + doi="10.17487/RFC7290", + } + +@misc{rfc7291, + author="M. Boucadair and R. Penno and D. Wing", + title="{DHCP Options for the Port Control Protocol (PCP)}", + howpublished="RFC 7291 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7291", + pages="1--11", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7291.txt", + key="RFC 7291", + abstract={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.}, + keywords="PCP Server discovery, Port Mapping, Shared Address", + doi="10.17487/RFC7291", + } + +@misc{rfc7292, + author="K. {Moriarty (Ed.)} and M. Nystrom and S. Parkinson and A. Rusch and M. Scott", + title="{PKCS \#12: Personal Information Exchange Syntax v1.1}", + howpublished="RFC 7292 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7292", + pages="1--29", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7292.txt", + key="RFC 7292", + abstract={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. 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.}, + keywords="PKCS\#12, PKCS12v1.1, PKCS\#12v1.1", + doi="10.17487/RFC7292", + } + +@misc{rfc7293, + author="W. Mills and M. Kucherawy", + title="{The Require-Recipient-Valid-Since Header Field and SMTP Service Extension}", + howpublished="RFC 7293 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7293", + pages="1--24", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7293.txt", + key="RFC 7293", + abstract={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. 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.}, + keywords="Security, Privacy, Email, Account Expiration", + doi="10.17487/RFC7293", + } + +@misc{rfc7294, + author="A. Clark and G. Zorn and C. Bi and Q. Wu", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications}", + howpublished="RFC 7294 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7294", + pages="1--22", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7294.txt", + key="RFC 7294", + abstract={This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.}, + keywords="Real Time Control Protocol", + doi="10.17487/RFC7294", + } + +@misc{rfc7295, + author="H. Tschofenig and L. Eggert and Z. Sarker", + title="{Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication}", + howpublished="RFC 7295 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7295", + pages="1--26", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7295.txt", + key="RFC 7295", + abstract={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. 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).}, + keywords="Congestion Control, RTCWEB, Workshop, Real-Time Communication", + doi="10.17487/RFC7295", + } + +@misc{rfc7296, + author="C. Kaufman and P. Hoffman and Y. Nir and P. Eronen and T. Kivinen", + title="{Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 7296 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="7296", + pages="1--142", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7427, 7670, 8247", +url="https://www.rfc-editor.org/rfc/rfc7296.txt", + key="RFC 7296", + abstract={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.}, + keywords="IKE, IPsec", + doi="10.17487/RFC7296", + } + +@misc{rfc7297, + author="M. Boucadair and C. Jacquenet and N. Wang", + title="{IP Connectivity Provisioning Profile (CPP)}", + howpublished="RFC 7297 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7297", + pages="1--22", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7297.txt", + key="RFC 7297", + abstract={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. 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.}, + doi="10.17487/RFC7297", + } + +@misc{rfc7298, + author="D. Ovsienko", + title="{Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication}", + howpublished="RFC 7298 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7298", + pages="1--55", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7298.txt", + key="RFC 7298", + abstract={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.}, + keywords="routing protocol, authentication, applied cryptography", + doi="10.17487/RFC7298", + } + +@misc{rfc7299, + author="R. Housley", + title="{Object Identifier Registry for the PKIX Working Group}", + howpublished="RFC 7299 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7299", + pages="1--30", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7299.txt", + key="RFC 7299", + abstract={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.}, + keywords="Public-Key Infrastructure using X.509", + doi="10.17487/RFC7299", + } + +@misc{rfc7300, + author="J. Haas and J. Mitchell", + title="{Reservation of Last Autonomous System (AS) Numbers}", + howpublished="RFC 7300 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7300", + pages="1--5", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7300.txt", + key="RFC 7300", + abstract={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.}, + keywords="asn, last asns", + doi="10.17487/RFC7300", + } + +@misc{rfc7301, + author="S. Friedl and A. Popov and A. Langley and E. Stephan", + title="{Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension}", + howpublished="RFC 7301 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7301", + pages="1--9", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8447", +url="https://www.rfc-editor.org/rfc/rfc7301.txt", + key="RFC 7301", + abstract={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.}, + keywords="ALPN", + doi="10.17487/RFC7301", + } + +@misc{rfc7302, + author="P. Lemieux", + title="{Entertainment Identifier Registry (EIDR) URN Namespace Definition}", + howpublished="RFC 7302 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7302", + pages="1--8", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7972", +url="https://www.rfc-editor.org/rfc/rfc7302.txt", + key="RFC 7302", + abstract={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.}, + keywords="EIDR, Entertainment Identifier Registry, URN", + doi="10.17487/RFC7302", + } + +@misc{rfc7303, + author="H. Thompson and C. Lilley", + title="{XML Media Types}", + howpublished="RFC 7303 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7303", + pages="1--35", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7303.txt", + key="RFC 7303", + abstract={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.}, + keywords="application/xml, application/xml-external-parsed-entity, application/xml-dtd, text/xml, text/xml-external-parsed-entity, +xml", + doi="10.17487/RFC7303", + } + +@misc{rfc7304, + author="W. Kumari", + title="{A Method for Mitigating Namespace Collisions}", + howpublished="RFC 7304 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7304", + pages="1--4", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7304.txt", + key="RFC 7304", + abstract={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.}, + doi="10.17487/RFC7304", + } + +@misc{rfc7305, + author="E. {Lear (Ed.)}", + title="{Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)}", + howpublished="RFC 7305 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7305", + pages="1--17", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7305.txt", + key="RFC 7305", + abstract={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. 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.}, + doi="10.17487/RFC7305", + } + +@misc{rfc7306, + author="H. Shah and F. Marti and W. Noureddine and A. Eiriksson and R. Sharp", + title="{Remote Direct Memory Access (RDMA) Protocol Extensions}", + howpublished="RFC 7306 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7306", + pages="1--34", + year=2014, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7306.txt", + key="RFC 7306", + abstract={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.}, + keywords="iWARP, RDMAP, DDP, RDMA, DMA", + doi="10.17487/RFC7306", + } + +@misc{rfc7307, + author="Q. Zhao and K. Raza and C. Zhou and L. Fang and L. Li and D. King", + title="{LDP Extensions for Multi-Topology}", + howpublished="RFC 7307 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7307", + pages="1--20", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7307.txt", + key="RFC 7307", + abstract={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. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.}, + keywords="MT, Label Distribution Protocol", + doi="10.17487/RFC7307", + } + +@misc{rfc7308, + author="E. Osborne", + title="{Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)}", + howpublished="RFC 7308 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7308", + pages="1--7", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7308.txt", + key="RFC 7308", + abstract={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). 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.}, + keywords="colors, link colors, igp te extensions", + doi="10.17487/RFC7308", + } + +@misc{rfc7309, + author="Z. Liu and L. Jin and R. Chen and D. Cai and S. Salam", + title="{Redundancy Mechanism for Inter-domain VPLS Service}", + howpublished="RFC 7309 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7309", + pages="1--12", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7309.txt", + key="RFC 7309", + abstract={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.}, + keywords="ICCP, PW", + doi="10.17487/RFC7309", + } + +@misc{rfc7310, + author="J. Lindsay and H. Foerster", + title="{RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs}", + howpublished="RFC 7310 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7310", + pages="1--16", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7310.txt", + key="RFC 7310", + abstract={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).}, + doi="10.17487/RFC7310", + } + +@misc{rfc7311, + author="P. Mohapatra and R. Fernando and E. Rosen and J. Uttaro", + title="{The Accumulated IGP Metric Attribute for BGP}", + howpublished="RFC 7311 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7311", + pages="1--15", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7311.txt", + key="RFC 7311", + abstract={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.}, + doi="10.17487/RFC7311", + } + +@misc{rfc7312, + author="J. Fabini and A. Morton", + title="{Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)}", + howpublished="RFC 7312 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7312", + pages="1--17", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7312.txt", + key="RFC 7312", + abstract={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.}, + keywords="Measurement, Wireless, Reactive, Repeatability, Continuity, Actionable, Conservative, Spatial Composition, Temporal Composition", + doi="10.17487/RFC7312", + } + +@misc{rfc7313, + author="K. Patel and E. Chen and B. Venkatachalapathy", + title="{Enhanced Route Refresh Capability for BGP-4}", + howpublished="RFC 7313 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7313", + pages="1--8", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7313.txt", + key="RFC 7313", + abstract={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.}, + keywords="Border Gateway Protocol, bgp rib, BGP Routing Information Base", + doi="10.17487/RFC7313", + } + +@misc{rfc7314, + author="M. Andrews", + title="{Extension Mechanisms for DNS (EDNS) EXPIRE Option}", + howpublished="RFC 7314 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7314", + pages="1--4", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7314.txt", + key="RFC 7314", + abstract={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.}, + keywords="IXFR, AXFR, zone, transfer, DNS, SOA", + doi="10.17487/RFC7314", + } + +@misc{rfc7315, + author="R. Jesske and K. Drage and C. Holmberg", + title="{Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP}", + howpublished="RFC 7315 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7315", + pages="1--43", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7913, 7976", +url="https://www.rfc-editor.org/rfc/rfc7315.txt", + key="RFC 7315", + abstract={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.}, + doi="10.17487/RFC7315", + } + +@misc{rfc7316, + author="J. van Elburg and K. Drage and M. Ohsugi and S. Schubert and K. Arai", + title="{The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header)}", + howpublished="RFC 7316 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7316", + pages="1--15", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7316.txt", + key="RFC 7316", + abstract={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.}, + doi="10.17487/RFC7316", + } + +@misc{rfc7317, + author="A. Bierman and M. Bjorklund", + title="{A YANG Data Model for System Management}", + howpublished="RFC 7317 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7317", + pages="1--35", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7317.txt", + key="RFC 7317", + abstract={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.}, + keywords="NETCONF", + doi="10.17487/RFC7317", + } + +@misc{rfc7318, + author="A. Newton and G. Huston", + title="{Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates}", + howpublished="RFC 7318 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7318", + pages="1--5", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7318.txt", + key="RFC 7318", + abstract={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.}, + doi="10.17487/RFC7318", + } + +@misc{rfc7319, + author="D. {Eastlake 3rd}", + title="{IANA Considerations for Connectivity Fault Management (CFM) Code Points}", + howpublished="RFC 7319 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7319", + pages="1--5", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7319.txt", + key="RFC 7319", + abstract={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.}, + keywords="CFM, OAM, Connectivity, Continuity, Fault, IANA, TRILL", + doi="10.17487/RFC7319", + } + +@misc{rfc7320, + author="M. Nottingham", + title="{URI Design and Ownership}", + howpublished="RFC 7320 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7320", + pages="1--9", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7320.txt", + key="RFC 7320", + abstract={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.}, + keywords="URI structure", + doi="10.17487/RFC7320", + } + +@misc{rfc7321, + author="D. McGrew and P. Hoffman", + title="{Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)}", + howpublished="RFC 7321 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7321", + pages="1--11", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8221", +url="https://www.rfc-editor.org/rfc/rfc7321.txt", + key="RFC 7321", + abstract={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. 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 cryptograph ic algorithms.}, + doi="10.17487/RFC7321", + } + +@misc{rfc7322, + author="H. Flanagan and S. Ginoza", + title="{RFC Style Guide}", + howpublished="RFC 7322 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7322", + pages="1--24", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7997", +url="https://www.rfc-editor.org/rfc/rfc7322.txt", + key="RFC 7322", + abstract={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''.}, + keywords="editorial guidance, format, style manual, house style", + doi="10.17487/RFC7322", + } + +@misc{rfc7323, + author="D. Borman and B. Braden and V. Jacobson and R. {Scheffenegger (Ed.)}", + title="{TCP Extensions for High Performance}", + howpublished="RFC 7323 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7323", + pages="1--49", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7323.txt", + key="RFC 7323", + abstract={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. This document obsoletes RFC 1323 and describes changes from it.}, + keywords="Timestamps, Timestamp, RTT, RTTM, Window Scale, PAWS, TCP options", + doi="10.17487/RFC7323", + } + +@misc{rfc7324, + author="E. Osborne", + title="{Updates to MPLS Transport Profile Linear Protection}", + howpublished="RFC 7324 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7324", + pages="1--11", + year=2014, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7324.txt", + key="RFC 7324", + abstract={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.}, + keywords="multiprotocol label switching, mpls-tp, psc, protection state coordination", + doi="10.17487/RFC7324", + } + +@misc{rfc7325, + author="C. {Villamizar (Ed.)} and K. Kompella and S. Amante and A. Malis and C. Pignataro", + title="{MPLS Forwarding Compliance and Performance Requirements}", + howpublished="RFC 7325 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7325", + pages="1--59", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7325.txt", + key="RFC 7325", + abstract={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.}, + keywords="MPLS, ECMP, link bundling, multipath, MPLS-TP, forwarding", + doi="10.17487/RFC7325", + } + +@misc{rfc7326, + author="J. Parello and B. Claise and B. Schoening and J. Quittek", + title="{Energy Management Framework}", + howpublished="RFC 7326 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7326", + pages="1--54", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7326.txt", + key="RFC 7326", + abstract={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.}, + doi="10.17487/RFC7326", + } + +@misc{rfc7328, + author="R. Gieben", + title="{Writing I-Ds and RFCs Using Pandoc and a Bit of XML}", + howpublished="RFC 7328 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7328", + pages="1--10", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7328.txt", + key="RFC 7328", + abstract={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. 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.}, + doi="10.17487/RFC7328", + } + +@misc{rfc7329, + author="H. Kaplan", + title="{A Session Identifier for the Session Initiation Protocol (SIP)}", + howpublished="RFC 7329 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7329", + pages="1--17", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7989", +url="https://www.rfc-editor.org/rfc/rfc7329.txt", + key="RFC 7329", + abstract={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. 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.}, + doi="10.17487/RFC7329", + } + +@misc{rfc7330, + author="T. Nadeau and Z. Ali and N. Akiya", + title="{Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management}", + howpublished="RFC 7330 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7330", + pages="1--11", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7330.txt", + key="RFC 7330", + abstract={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.}, + keywords="Network Management, management Information Base, MIB, SMIv2, BFD", + doi="10.17487/RFC7330", + } + +@misc{rfc7331, + author="T. Nadeau and Z. Ali and N. Akiya", + title="{Bidirectional Forwarding Detection (BFD) Management Information Base}", + howpublished="RFC 7331 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7331", + pages="1--39", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7331.txt", + key="RFC 7331", + abstract={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.}, + keywords="Network Management, Management Information Base, MIB, SMIv2, BFD", + doi="10.17487/RFC7331", + } + +@misc{rfc7332, + author="H. Kaplan and V. Pascual", + title="{Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)}", + howpublished="RFC 7332 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7332", + pages="1--5", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7332.txt", + key="RFC 7332", + abstract={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.}, + doi="10.17487/RFC7332", + } + +@misc{rfc7333, + author="H. {Chan (Ed.)} and D. Liu and P. Seite and H. Yokota and J. Korhonen", + title="{Requirements for Distributed Mobility Management}", + howpublished="RFC 7333 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7333", + pages="1--24", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7333.txt", + key="RFC 7333", + abstract={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.}, + keywords="Distributed Mobility Management, Network function distribution, Flat mobile network, Mobile network operation and management, Control and data plane separation", + doi="10.17487/RFC7333", + } + +@misc{rfc7334, + author="Q. Zhao and D. Dhody and D. King and Z. Ali and R. Casellas", + title="{PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths}", + howpublished="RFC 7334 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7334", + pages="1--25", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7334.txt", + key="RFC 7334", + abstract={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. 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.}, + keywords="Core-tree", + doi="10.17487/RFC7334", + } + +@misc{rfc7335, + author="C. Byrne", + title="{IPv4 Service Continuity Prefix}", + howpublished="RFC 7335 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7335", + pages="1--4", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7335.txt", + key="RFC 7335", + abstract={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.}, + doi="10.17487/RFC7335", + } + +@misc{rfc7336, + author="L. Peterson and B. Davie and R. van {Brandenburg (Ed.)}", + title="{Framework for Content Distribution Network Interconnection (CDNI)}", + howpublished="RFC 7336 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7336", + pages="1--58", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7336.txt", + key="RFC 7336", + abstract={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.}, + keywords="CDNI, content delivery network, federation, cdni request routing, cdni logging, cdmi metadata, cdni control", + doi="10.17487/RFC7336", + } + +@misc{rfc7337, + author="K. {Leung (Ed.)} and Y. {Lee (Ed.)}", + title="{Content Distribution Network Interconnection (CDNI) Requirements}", + howpublished="RFC 7337 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7337", + pages="1--23", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7337.txt", + key="RFC 7337", + abstract={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. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.}, + doi="10.17487/RFC7337", + } + +@misc{rfc7338, + author="F. {Jounay (Ed.)} and Y. {Kamite (Ed.)} and G. Heron and M. Bocci", + title="{Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks}", + howpublished="RFC 7338 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7338", + pages="1--18", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7338.txt", + key="RFC 7338", + abstract={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).}, + doi="10.17487/RFC7338", + } + +@misc{rfc7339, + author="V. {Gurbani (Ed.)} and V. Hilt and H. Schulzrinne", + title="{Session Initiation Protocol (SIP) Overload Control}", + howpublished="RFC 7339 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7339", + pages="1--38", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7339.txt", + key="RFC 7339", + abstract={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.}, + keywords="SIP, Overload Control", + doi="10.17487/RFC7339", + } + +@misc{rfc7340, + author="J. Peterson and H. Schulzrinne and H. Tschofenig", + title="{Secure Telephone Identity Problem Statement and Requirements}", + howpublished="RFC 7340 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7340", + pages="1--25", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7340.txt", + key="RFC 7340", + abstract={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 s olution in this space.}, + keywords="SIP, XMPP, Secure Origin Identification, Communication Security, RTCWeb, Problem Statement, Real-Time Communication", + doi="10.17487/RFC7340", + } + +@misc{rfc7341, + author="Q. Sun and Y. Cui and M. Siodelski and S. Krishnan and I. Farrer", + title="{DHCPv4-over-DHCPv6 (DHCP 4o6) Transport}", + howpublished="RFC 7341 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7341", + pages="1--16", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7341.txt", + key="RFC 7341", + abstract={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.}, + keywords="ipv6, transition, softwire, migration, tunnel, residual, ipv4, dhcpv6, relay, ipv6-only", + doi="10.17487/RFC7341", + } + +@misc{rfc7342, + author="L. Dunbar and W. Kumari and I. Gashinsky", + title="{Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers}", + howpublished="RFC 7342 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7342", + pages="1--14", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7342.txt", + key="RFC 7342", + abstract={This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.}, + doi="10.17487/RFC7342", + } + +@misc{rfc7343, + author="J. Laganier and F. Dupont", + title="{An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)}", + howpublished="RFC 7343 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7343", + pages="1--14", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7343.txt", + key="RFC 7343", + abstract={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. 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.}, + keywords="HIP, HIPv2, ORCHID, CGA, API", + doi="10.17487/RFC7343", + } + +@misc{rfc7344, + author="W. Kumari and O. Gudmundsson and G. Barwood", + title="{Automating DNSSEC Delegation Trust Maintenance}", + howpublished="RFC 7344 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7344", + pages="1--18", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8078", +url="https://www.rfc-editor.org/rfc/rfc7344.txt", + key="RFC 7344", + abstract={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.}, + keywords="key roll, trust anchor, CDS, CDNSKEY, DNSSEC, DNS", + doi="10.17487/RFC7344", + } + +@misc{rfc7345, + author="C. Holmberg and I. Sedlacek and G. Salgueiro", + title="{UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 7345 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7345", + pages="1--23", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7345.txt", + key="RFC 7345", + abstract={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).}, + keywords="SDP, SIP, DTLS, UDPTL, fax, transport", + doi="10.17487/RFC7345", + } + +@misc{rfc7346, + author="R. Droms", + title="{IPv6 Multicast Address Scopes}", + howpublished="RFC 7346 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7346", + pages="1--6", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7346.txt", + key="RFC 7346", + abstract={This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.}, + keywords="IPv6 multicast address scopes", + doi="10.17487/RFC7346", + } + +@misc{rfc7347, + author="H. van {Helvoort (Ed.)} and J. {Ryoo (Ed.)} and H. Zhang and F. Huang and H. Li and A. D'Alessandro", + title="{Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)}", + howpublished="RFC 7347 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7347", + pages="1--32", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7347.txt", + key="RFC 7347", + abstract={The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324. 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. 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.}, + doi="10.17487/RFC7347", + } + +@misc{rfc7348, + author="M. Mahalingam and D. Dutt and K. Duda and P. Agarwal and L. Kreeger and T. Sridhar and M. Bursell and C. Wright", + title="{Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks}", + howpublished="RFC 7348 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7348", + pages="1--22", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7348.txt", + key="RFC 7348", + abstract={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.}, + doi="10.17487/RFC7348", + } + +@misc{rfc7349, + author="L. Zheng and M. Chen and M. Bhatia", + title="{LDP Hello Cryptographic Authentication}", + howpublished="RFC 7349 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7349", + pages="1--14", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7349.txt", + key="RFC 7349", + abstract={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.}, + doi="10.17487/RFC7349", + } + +@misc{rfc7350, + author="M. Petit-Huguenin and G. Salgueiro", + title="{Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)}", + howpublished="RFC 7350 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7350", + pages="1--16", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7350.txt", + key="RFC 7350", + abstract={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.}, + keywords="Security, Encryption", + doi="10.17487/RFC7350", + } + +@misc{rfc7351, + author="E. Wilde", + title="{A Media Type for XML Patch Operations}", + howpublished="RFC 7351 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7351", + pages="1--14", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7351.txt", + key="RFC 7351", + abstract={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.}, + keywords="Media Type, XML Patch Operations", + doi="10.17487/RFC7351", + } + +@misc{rfc7352, + author="S. Bosch", + title="{Sieve Email Filtering: Detecting Duplicate Deliveries}", + howpublished="RFC 7352 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7352", + pages="1--15", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7352.txt", + key="RFC 7352", + abstract={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.}, + keywords="sieve, duplicate deliveries", + doi="10.17487/RFC7352", + } + +@misc{rfc7353, + author="S. Bellovin and R. Bush and D. Ward", + title="{Security Requirements for BGP Path Validation}", + howpublished="RFC 7353 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7353", + pages="1--9", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7353.txt", + key="RFC 7353", + abstract={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.}, + keywords="Routing, BGP, Security, AS\_PATH, and RPKI", + doi="10.17487/RFC7353", + } + +@misc{rfc7354, + author="A. Adolf and P. Siebert", + title="{Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace}", + howpublished="RFC 7354 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7354", + pages="1--3", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7354.txt", + key="RFC 7354", + abstract={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.}, + doi="10.17487/RFC7354", + } + +@misc{rfc7355, + author="G. Salgueiro and V. Pascual and A. Roman and S. Garcia", + title="{Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF)}", + howpublished="RFC 7355 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7355", + pages="1--9", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7355.txt", + key="RFC 7355", + abstract={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.}, + doi="10.17487/RFC7355", + } + +@misc{rfc7356, + author="L. Ginsberg and S. Previdi and Y. Yang", + title="{IS-IS Flooding Scope Link State PDUs (LSPs)}", + howpublished="RFC 7356 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7356", + pages="1--23", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7356.txt", + key="RFC 7356", + abstract={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. The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.}, + doi="10.17487/RFC7356", + } + +@misc{rfc7357, + author="H. Zhai and F. Hu and R. Perlman and D. {Eastlake 3rd} and O. Stokes", + title="{Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol}", + howpublished="RFC 7357 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7357", + pages="1--31", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7357.txt", + key="RFC 7357", + abstract={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). 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.}, + keywords="ESADI, TRILL, RBridge, Address Learning, Reachability, MAC Addresses", + doi="10.17487/RFC7357", + } + +@misc{rfc7358, + author="K. Raza and S. Boutros and L. Martini and N. Leymann", + title="{Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)}", + howpublished="RFC 7358 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7358", + pages="1--8", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7358.txt", + key="RFC 7358", + abstract={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.}, + doi="10.17487/RFC7358", + } + +@misc{rfc7359, + author="F. Gont", + title="{Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks}", + howpublished="RFC 7359 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7359", + pages="1--12", + year=2014, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7359.txt", + key="RFC 7359", + abstract={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.}, + doi="10.17487/RFC7359", + } + +@misc{rfc7360, + author="A. DeKok", + title="{Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS}", + howpublished="RFC 7360 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7360", + pages="1--27", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7360.txt", + key="RFC 7360", + abstract={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.}, + doi="10.17487/RFC7360", + } + +@misc{rfc7361, + author="P. Dutta and F. Balus and O. Stokes and G. Calvignac and D. Fedyk", + title="{LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)}", + howpublished="RFC 7361 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7361", + pages="1--27", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7361.txt", + key="RFC 7361", + abstract={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.}, + keywords="MAC flush message, MAC Flush TLV, MAC flushing", + doi="10.17487/RFC7361", + } + +@misc{rfc7362, + author="E. Ivov and H. Kaplan and D. Wing", + title="{Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication}", + howpublished="RFC 7362 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7362", + pages="1--16", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7362.txt", + key="RFC 7362", + abstract={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. 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. 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.}, + keywords="VoIP, firewall traversal", + doi="10.17487/RFC7362", + } + +@misc{rfc7363, + author="J. Maenpaa and G. Camarillo", + title="{Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)}", + howpublished="RFC 7363 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7363", + pages="1--22", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7363.txt", + key="RFC 7363", + abstract={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.}, + keywords="P2PSIP, P2P, Chord", + doi="10.17487/RFC7363", + } + +@misc{rfc7364, + author="T. {Narten (Ed.)} and E. {Gray (Ed.)} and D. Black and L. Fang and L. Kreeger and M. Napierala", + title="{Problem Statement: Overlays for Network Virtualization}", + howpublished="RFC 7364 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7364", + pages="1--23", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7364.txt", + key="RFC 7364", + abstract={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.}, + doi="10.17487/RFC7364", + } + +@misc{rfc7365, + author="M. Lasserre and F. Balus and T. Morin and N. Bitar and Y. Rekhter", + title="{Framework for Data Center (DC) Network Virtualization}", + howpublished="RFC 7365 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7365", + pages="1--26", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7365.txt", + key="RFC 7365", + abstract={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.}, + keywords="nvo3, network virtualization over layer 3", + doi="10.17487/RFC7365", + } + +@misc{rfc7366, + author="P. Gutmann", + title="{Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 7366 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7366", + pages="1--7", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7366.txt", + key="RFC 7366", + abstract={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.}, + doi="10.17487/RFC7366", + } + +@misc{rfc7367, + author="R. Cole and J. Macker and B. Adamson", + title="{Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process}", + howpublished="RFC 7367 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7367", + pages="1--65", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7367.txt", + key="RFC 7367", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects 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.}, + keywords="Network Management, Management Information Base, MIB, SMIv2, Routing, MANET, Multicast", + doi="10.17487/RFC7367", + } + +@misc{rfc7368, + author="T. {Chown (Ed.)} and J. Arkko and A. Brandt and O. Troan and J. Weil", + title="{IPv6 Home Networking Architecture Principles}", + howpublished="RFC 7368 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7368", + pages="1--49", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7368.txt", + key="RFC 7368", + abstract={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.}, + keywords="IPv6", + doi="10.17487/RFC7368", + } + +@misc{rfc7369, + author="A. Takacs and B. Gero and H. Long", + title="{GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration}", + howpublished="RFC 7369 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7369", + pages="1--18", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7369.txt", + key="RFC 7369", + abstract={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.}, + keywords="GELS, Ethernet Label Switching, PBB-TE, connectivity monitoring, OAM configuration", + doi="10.17487/RFC7369", + } + +@misc{rfc7370, + author="L. Ginsberg", + title="{Updates to the IS-IS TLV Codepoints Registry}", + howpublished="RFC 7370 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7370", + pages="1--7", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7370.txt", + key="RFC 7370", + abstract={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.}, + keywords="Codepoint", + doi="10.17487/RFC7370", + } + +@misc{rfc7371, + author="M. Boucadair and S. Venaas", + title="{Updates to the IPv6 Multicast Addressing Architecture}", + howpublished="RFC 7371 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7371", + pages="1--10", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7371.txt", + key="RFC 7371", + abstract={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. This document updates RFCs 3956, 3306, and 4291.}, + keywords="IPv6 Multicast Flag Bits, updated unicast-prefix-based address, updated Embedded-RP", + doi="10.17487/RFC7371", + } + +@misc{rfc7372, + author="M. Kucherawy", + title="{Email Authentication Status Codes}", + howpublished="RFC 7372 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7372", + pages="1--8", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7372.txt", + key="RFC 7372", + abstract={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. This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.}, + doi="10.17487/RFC7372", + } + +@misc{rfc7373, + author="B. Trammell", + title="{Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types}", + howpublished="RFC 7373 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7373", + pages="1--14", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7373.txt", + key="RFC 7373", + abstract={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.}, + keywords="information element, unicode", + doi="10.17487/RFC7373", + } + +@misc{rfc7374, + author="J. Maenpaa and G. Camarillo", + title="{Service Discovery Usage for REsource LOcation And Discovery (RELOAD)}", + howpublished="RFC 7374 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7374", + pages="1--20", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7374.txt", + key="RFC 7374", + abstract={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.}, + keywords="P2PSIP, ReDiR, P2P, DHT", + doi="10.17487/RFC7374", + } + +@misc{rfc7375, + author="J. Peterson", + title="{Secure Telephone Identity Threat Model}", + howpublished="RFC 7375 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7375", + pages="1--13", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7375.txt", + key="RFC 7375", + abstract={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.}, + keywords="SIP, Secure Origin Identification, Communication Security, RTCWeb, Threat, Real-Time Communication", + doi="10.17487/RFC7375", + } + +@misc{rfc7376, + author="T. Reddy and R. Ravindranath and M. Perumal and A. Yegin", + title="{Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)}", + howpublished="RFC 7376 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7376", + pages="1--8", + year=2014, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7376.txt", + key="RFC 7376", + abstract={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.}, + doi="10.17487/RFC7376", + } + +@misc{rfc7377, + author="B. Leiba and A. Melnikov", + title="{IMAP4 Multimailbox SEARCH Extension}", + howpublished="RFC 7377 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7377", + pages="1--11", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7377.txt", + key="RFC 7377", + abstract={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.}, + keywords="IMAP, email, search, multiple mailboxes, imapext", + doi="10.17487/RFC7377", + } + +@misc{rfc7378, + author="H. Tschofenig and H. Schulzrinne and B. {Aboba (Ed.)}", + title="{Trustworthy Location}", + howpublished="RFC 7378 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7378", + pages="1--31", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7378.txt", + key="RFC 7378", + abstract={The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance. 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.}, + doi="10.17487/RFC7378", + } + +@misc{rfc7379, + author="Y. Li and W. Hao and R. Perlman and J. Hudson and H. Zhai", + title="{Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge}", + howpublished="RFC 7379 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7379", + pages="1--13", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7379.txt", + key="RFC 7379", + abstract={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.}, + doi="10.17487/RFC7379", + } + +@misc{rfc7380, + author="J. Tong and C. {Bi (Ed.)} and R. Even and Q. {Wu (Ed.)} and R. Huang", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting}", + howpublished="RFC 7380 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7380", + pages="1--11", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7380.txt", + key="RFC 7380", + abstract={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.}, + keywords="TR 101 290", + doi="10.17487/RFC7380", + } + +@misc{rfc7381, + author="K. Chittimaneni and T. Chown and L. Howard and V. Kuarsingh and Y. Pouffary and E. Vyncke", + title="{Enterprise IPv6 Deployment Guidelines}", + howpublished="RFC 7381 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7381", + pages="1--34", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7381.txt", + key="RFC 7381", + abstract={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.}, + keywords="IPV6 migration transition enterprise", + doi="10.17487/RFC7381", + } + +@misc{rfc7382, + author="S. Kent and D. Kong and K. Seo", + title="{Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)}", + howpublished="RFC 7382 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7382", + pages="1--38", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7382.txt", + key="RFC 7382", + abstract={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.}, + doi="10.17487/RFC7382", + } + +@misc{rfc7383, + author="V. Smyslov", + title="{Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation}", + howpublished="RFC 7383 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7383", + pages="1--20", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7383.txt", + key="RFC 7383", + abstract={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.}, + keywords="IP fragmentation, NAT, firewall, PMTU discovery", + doi="10.17487/RFC7383", + } + +@misc{rfc7384, + author="T. Mizrahi", + title="{Security Requirements of Time Protocols in Packet Switched Networks}", + howpublished="RFC 7384 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7384", + pages="1--36", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7384.txt", + key="RFC 7384", + abstract={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.}, + keywords="ptp, precision time protocol, ntp, network time protocol", + doi="10.17487/RFC7384", + } + +@misc{rfc7385, + author="L. Andersson and G. Swallow", + title="{IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points}", + howpublished="RFC 7385 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7385", + pages="1--4", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 8317, 8338", +url="https://www.rfc-editor.org/rfc/rfc7385.txt", + key="RFC 7385", + abstract={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. 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.}, + doi="10.17487/RFC7385", + } + +@misc{rfc7386, + author="P. Hoffman and J. Snell", + title="{JSON Merge Patch}", + howpublished="RFC 7386 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7386", + pages="1--9", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7396", +url="https://www.rfc-editor.org/rfc/rfc7386.txt", + key="RFC 7386", + abstract={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.}, + keywords="http, json, patch, merge", + doi="10.17487/RFC7386", + } + +@misc{rfc7387, + author="R. {Key (Ed.)} and L. {Yong (Ed.)} and S. Delord and F. Jounay and L. Jin", + title="{A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network}", + howpublished="RFC 7387 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7387", + pages="1--13", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7387.txt", + key="RFC 7387", + abstract={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.}, + keywords="mef, etherhet lan, e-lan, metro ethernet forum", + doi="10.17487/RFC7387", + } + +@misc{rfc7388, + author="J. Schoenwaelder and A. Sehgal and T. Tsou and C. Zhou", + title="{Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}", + howpublished="RFC 7388 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7388", + pages="1--27", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7388.txt", + key="RFC 7388", + abstract={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).}, + keywords="Network Management, Management Information Base, MIB, SMIv2", + doi="10.17487/RFC7388", + } + +@misc{rfc7389, + author="R. Wakikawa and R. Pazhyannur and S. Gundavelli and C. Perkins", + title="{Separation of Control and User Plane for Proxy Mobile IPv6}", + howpublished="RFC 7389 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7389", + pages="1--12", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7389.txt", + key="RFC 7389", + abstract={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.}, + keywords="Control and User Plane Split, Control and User Plane Separation, LMA User-Plane Address Mobility Option", + doi="10.17487/RFC7389", + } + +@misc{rfc7390, + author="A. {Rahman (Ed.)} and E. {Dijk (Ed.)}", + title="{Group Communication for the Constrained Application Protocol (CoAP)}", + howpublished="RFC 7390 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7390", + pages="1--46", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7390.txt", + key="RFC 7390", + abstract={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.}, + keywords="multicast, IP multicast, RESTful, Internet of Things (IoT)", + doi="10.17487/RFC7390", + } + +@misc{rfc7391, + author="J. Hadi Salim", + title="{Forwarding and Control Element Separation (ForCES) Protocol Extensions}", + howpublished="RFC 7391 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7391", + pages="1--23", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7391.txt", + key="RFC 7391", + abstract={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.}, + keywords="ForCES, Protocol, Extension", + doi="10.17487/RFC7391", + } + +@misc{rfc7392, + author="P. Dutta and M. Bocci and L. Martini", + title="{Explicit Path Routing for Dynamic Multi-Segment Pseudowires}", + howpublished="RFC 7392 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7392", + pages="1--10", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7392.txt", + key="RFC 7392", + abstract={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.}, + keywords="Pseudowire, MS-PW, explicit route", + doi="10.17487/RFC7392", + } + +@misc{rfc7393, + author="X. Deng and M. Boucadair and Q. Zhao and J. Huang and C. Zhou", + title="{Using the Port Control Protocol (PCP) to Update Dynamic DNS}", + howpublished="RFC 7393 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7393", + pages="1--14", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7393.txt", + key="RFC 7393", + abstract={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.}, + keywords="address sharing, CGN, service continuity, service availability, user-generated content, address-sharing issues, DS-Lite, service delivery in CGN contexts", + doi="10.17487/RFC7393", + } + +@misc{rfc7394, + author="S. Boutros and S. Sivabalan and G. Swallow and S. Saxena and V. Manral and S. Aldrin", + title="{Definition of Time to Live TLV for LSP-Ping Mechanisms}", + howpublished="RFC 7394 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7394", + pages="1--8", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7394.txt", + key="RFC 7394", + abstract={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.}, + doi="10.17487/RFC7394", + } + +@misc{rfc7395, + author="L. {Stout (Ed.)} and J. Moffitt and E. Cestari", + title="{An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket}", + howpublished="RFC 7395 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7395", + pages="1--18", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7395.txt", + key="RFC 7395", + abstract={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.}, + keywords="WebSocket, XMPP", + doi="10.17487/RFC7395", + } + +@misc{rfc7396, + author="P. Hoffman and J. Snell", + title="{JSON Merge Patch}", + howpublished="RFC 7396 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7396", + pages="1--9", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7396.txt", + key="RFC 7396", + abstract={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.}, + keywords="http, json, patch, merge", + doi="10.17487/RFC7396", + } + +@misc{rfc7397, + author="J. Gilger and H. Tschofenig", + title="{Report from the Smart Object Security Workshop}", + howpublished="RFC 7397 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7397", + pages="1--23", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7397.txt", + key="RFC 7397", + abstract={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. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.}, + keywords="Smart Objects, Internet of Things, Workshop, Security", + doi="10.17487/RFC7397", + } + +@misc{rfc7398, + author="M. Bagnulo and T. Burbridge and S. Crawford and P. Eardley and A. Morton", + title="{A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance}", + howpublished="RFC 7398 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7398", + pages="1--17", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7398.txt", + key="RFC 7398", + abstract={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.}, + keywords="LMAP, performance metrics", + doi="10.17487/RFC7398", + } + +@misc{rfc7399, + author="A. Farrel and D. King", + title="{Unanswered Questions in the Path Computation Element Architecture}", + howpublished="RFC 7399 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7399", + pages="1--29", + year=2014, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7399.txt", + key="RFC 7399", + abstract={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. 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. 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.}, + keywords="SDN, Software Defined Networking, H-PCE, Hierarchical PCE, VNTM, Virtual Network Topology Manager, ABNO, Application-Based Network Operation, TE, Traffic Engineering", + doi="10.17487/RFC7399", + } + +@misc{rfc7400, + author="C. Bormann", + title="{6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)}", + howpublished="RFC 7400 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7400", + pages="1--24", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7400.txt", + key="RFC 7400", + abstract={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.}, + keywords="IoT, Internet of Things, Embedded Internet, Sensor Network, WSN, Constrained node, Constrained network, Constrained-node network, LLN, LoWPAN, packet encoding, capability indication, 6CIO, LZ77, RFC 6282, RFC 4944, adaptation layer, IEEE 802.15.4", + doi="10.17487/RFC7400", + } + +@misc{rfc7401, + author="R. {Moskowitz (Ed.)} and T. Heer and P. Jokela and T. Henderson", + title="{Host Identity Protocol Version 2 (HIPv2)}", + howpublished="RFC 7401 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7401", + pages="1--128", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8002", +url="https://www.rfc-editor.org/rfc/rfc7401.txt", + key="RFC 7401", + abstract={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. 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.}, + keywords="HIP, IP-layer state, integrity protection, optional encryption", + doi="10.17487/RFC7401", + } + +@misc{rfc7402, + author="P. Jokela and R. Moskowitz and J. Melen", + title="{Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)}", + howpublished="RFC 7402 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7402", + pages="1--40", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7402.txt", + key="RFC 7402", + abstract={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.}, + keywords="encryption, user data packets", + doi="10.17487/RFC7402", + } + +@misc{rfc7403, + author="H. Kaplan", + title="{A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)}", + howpublished="RFC 7403 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7403", + pages="1--7", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7403.txt", + key="RFC 7403", + abstract={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).}, + doi="10.17487/RFC7403", + } + +@misc{rfc7404, + author="M. Behringer and E. Vyncke", + title="{Using Only Link-Local Addressing inside an IPv6 Network}", + howpublished="RFC 7404 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7404", + pages="1--10", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7404.txt", + key="RFC 7404", + abstract={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.}, + keywords="IPv6 security routing, Link-Local, Routing Protocol, Security", + doi="10.17487/RFC7404", + } + +@misc{rfc7405, + author="P. Kyzivat", + title="{Case-Sensitive String Support in ABNF}", + howpublished="RFC 7405 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7405", + pages="1--4", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7405.txt", + key="RFC 7405", + abstract={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.}, + keywords="BNF, ABNF Syntax", + doi="10.17487/RFC7405", + } + +@misc{rfc7406, + author="H. Schulzrinne and S. McCann and G. Bajko and H. Tschofenig and D. Kroeselberg", + title="{Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices}", + howpublished="RFC 7406 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7406", + pages="1--25", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7406.txt", + key="RFC 7406", + abstract={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.}, + doi="10.17487/RFC7406", + } + +@misc{rfc7407, + author="M. Bjorklund and J. Schoenwaelder", + title="{A YANG Data Model for SNMP Configuration}", + howpublished="RFC 7407 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7407", + pages="1--88", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7407.txt", + key="RFC 7407", + abstract={This document defines a collection of YANG definitions for configuring SNMP engines.}, + doi="10.17487/RFC7407", + } + +@misc{rfc7408, + author="E. Haleplidis", + title="{Forwarding and Control Element Separation (ForCES) Model Extension}", + howpublished="RFC 7408 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7408", + pages="1--31", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7408.txt", + key="RFC 7408", + abstract={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.}, + keywords="ForCES, Model, Extension", + doi="10.17487/RFC7408", + } + +@misc{rfc7409, + author="E. Haleplidis and J. Halpern", + title="{Forwarding and Control Element Separation (ForCES) Packet Parallelization}", + howpublished="RFC 7409 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7409", + pages="1--27", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7409.txt", + key="RFC 7409", + abstract={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).}, + keywords="ForCES, Model, Extension", + doi="10.17487/RFC7409", + } + +@misc{rfc7410, + author="M. Kucherawy", + title="{A Property Types Registry for the Authentication-Results Header Field}", + howpublished="RFC 7410 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7410", + pages="1--5", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7601", +url="https://www.rfc-editor.org/rfc/rfc7410.txt", + key="RFC 7410", + abstract={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.}, + keywords="Authentication-Results, Reputation", + doi="10.17487/RFC7410", + } + +@misc{rfc7411, + author="T. {Schmidt (Ed.)} and M. Waehlisch and R. Koodli and G. Fairhurst and D. Liu", + title="{Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers}", + howpublished="RFC 7411 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7411", + pages="1--30", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7411.txt", + key="RFC 7411", + abstract={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 updat ed Proxy Router Advertisements message format. This document updates RFC 5568, ``Mobile IPv6 Fast Handovers''.}, + keywords="Multicast, Mobility, IPv6, PIM, MLD, Group Communication", + doi="10.17487/RFC7411", + } + +@misc{rfc7412, + author="Y. Weingarten and S. Aldrin and P. Pan and J. Ryoo and G. Mirsky", + title="{Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection}", + howpublished="RFC 7412 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7412", + pages="1--16", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7412.txt", + key="RFC 7412", + abstract={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.}, + doi="10.17487/RFC7412", + } + +@misc{rfc7413, + author="Y. Cheng and J. Chu and S. Radhakrishnan and A. Jain", + title="{TCP Fast Open}", + howpublished="RFC 7413 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7413", + pages="1--26", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7413.txt", + key="RFC 7413", + abstract={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.}, + doi="10.17487/RFC7413", + } + +@misc{rfc7414, + author="M. Duke and R. Braden and W. Eddy and E. Blanton and A. Zimmermann", + title="{A Roadmap for Transmission Control Protocol (TCP) Specification Documents}", + howpublished="RFC 7414 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7414", + pages="1--57", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7805", +url="https://www.rfc-editor.org/rfc/rfc7414.txt", + key="RFC 7414", + abstract={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. This document obsoletes RFC 4614.}, + keywords="TCP Roadmap", + doi="10.17487/RFC7414", + } + +@misc{rfc7415, + author="E. Noel and P. Williams", + title="{Session Initiation Protocol (SIP) Rate Control}", + howpublished="RFC 7415 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7415", + pages="1--15", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7415.txt", + key="RFC 7415", + abstract={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.}, + doi="10.17487/RFC7415", + } + +@misc{rfc7416, + author="T. Tsao and R. Alexander and M. Dohler and V. Daza and A. Lozano and M. {Richardson (Ed.)}", + title="{A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)}", + howpublished="RFC 7416 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7416", + pages="1--40", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7416.txt", + key="RFC 7416", + abstract={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.}, + keywords="LLN, ROLL, security", + doi="10.17487/RFC7416", + } + +@misc{rfc7417, + author="G. Karagiannis and A. Bhargava", + title="{Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains}", + howpublished="RFC 7417 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7417", + pages="1--36", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7417.txt", + key="RFC 7417", + abstract={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.}, + keywords="generic aggregate rsvp", + doi="10.17487/RFC7417", + } + +@misc{rfc7418, + author="S. {Dawkins (Ed.)}", + title="{An IRTF Primer for IETF Participants}", + howpublished="RFC 7418 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7418", + pages="1--7", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7418.txt", + key="RFC 7418", + abstract={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.}, + keywords="Research Group", + doi="10.17487/RFC7418", + } + +@misc{rfc7419, + author="N. Akiya and M. Binderberger and G. Mirsky", + title="{Common Interval Support in Bidirectional Forwarding Detection}", + howpublished="RFC 7419 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7419", + pages="1--8", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7419.txt", + key="RFC 7419", + abstract={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. 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.}, + keywords="BFD, hardware, interval, timer", + doi="10.17487/RFC7419", + } + +@misc{rfc7420, + author="A. Koushik and E. Stephan and Q. Zhao and D. King and J. Hardwick", + title="{Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module}", + howpublished="RFC 7420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7420", + pages="1--65", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7420.txt", + key="RFC 7420", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for 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.}, + keywords="Network Management, Management Information Base, MIB, SMIv2, PCE, PCEP", + doi="10.17487/RFC7420", + } + +@misc{rfc7421, + author="B. {Carpenter (Ed.)} and T. Chown and F. Gont and S. Jiang and A. Petrescu and A. Yourtchenko", + title="{Analysis of the 64-bit Boundary in IPv6 Addressing}", + howpublished="RFC 7421 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7421", + pages="1--24", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7421.txt", + key="RFC 7421", + abstract={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.}, + doi="10.17487/RFC7421", + } + +@misc{rfc7422, + author="C. Donley and C. Grundemann and V. Sarawat and K. Sundaresan and O. Vautrin", + title="{Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments}", + howpublished="RFC 7422 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7422", + pages="1--14", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7422.txt", + key="RFC 7422", + abstract={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.}, + doi="10.17487/RFC7422", + } + +@misc{rfc7423, + author="L. {Morand (Ed.)} and V. Fajardo and H. Tschofenig", + title="{Diameter Applications Design Guidelines}", + howpublished="RFC 7423 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7423", + pages="1--29", + year=2014, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7423.txt", + key="RFC 7423", + abstract={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.}, + keywords="AAA, Authentication, Authorization, Accounting", + doi="10.17487/RFC7423", + } + +@misc{rfc7424, + author="R. Krishnan and L. Yong and A. Ghanwani and N. So and B. Khasnabish", + title="{Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks}", + howpublished="RFC 7424 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7424", + pages="1--29", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7424.txt", + key="RFC 7424", + abstract={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.}, + doi="10.17487/RFC7424", + } + +@misc{rfc7425, + author="M. Thornburgh", + title="{Adobe's RTMFP Profile for Flash Communication}", + howpublished="RFC 7425 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7425", + pages="1--49", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7425.txt", + key="RFC 7425", + abstract={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.}, + doi="10.17487/RFC7425", + } + +@misc{rfc7426, + author="E. {Haleplidis (Ed.)} and K. {Pentikousis (Ed.)} and S. Denazis and J. Hadi Salim and D. Meyer and O. Koufopavlou", + title="{Software-Defined Networking (SDN): Layers and Architecture Terminology}", + howpublished="RFC 7426 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7426", + pages="1--35", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7426.txt", + key="RFC 7426", + abstract={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.}, + keywords="Software-defined Networking, SDN, Programmable Networks, Architecture, Layer, Terminology", + doi="10.17487/RFC7426", + } + +@misc{rfc7427, + author="T. Kivinen and J. Snyder", + title="{Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)}", + howpublished="RFC 7427 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7427", + pages="1--18", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7427.txt", + key="RFC 7427", + abstract={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.}, + keywords="IPsec, IKE, IKEv2, Signature, Authentication, RSA, DSS, DSA, ECDSA, SASSA-PSS, PKIX", + doi="10.17487/RFC7427", + } + +@misc{rfc7428, + author="A. Brandt and J. Buron", + title="{Transmission of IPv6 Packets over ITU-T G.9959 Networks}", + howpublished="RFC 7428 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7428", + pages="1--21", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7428.txt", + key="RFC 7428", + abstract={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.}, + doi="10.17487/RFC7428", + } + +@misc{rfc7429, + author="D. {Liu (Ed.)} and JC. {Zuniga (Ed.)} and P. Seite and H. Chan and CJ. Bernardos", + title="{Distributed Mobility Management: Current Practices and Gap Analysis}", + howpublished="RFC 7429 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7429", + pages="1--34", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7429.txt", + key="RFC 7429", + abstract={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.}, + keywords="DMM, Distributed Mobility Management, anchor, gap analysis, best practices", + doi="10.17487/RFC7429", + } + +@misc{rfc7430, + author="M. Bagnulo and C. Paasch and F. Gont and O. Bonaventure and C. Raiciu", + title="{Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)}", + howpublished="RFC 7430 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7430", + pages="1--19", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7430.txt", + key="RFC 7430", + abstract={This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.}, + keywords="MPTCP, security, threat analysis", + doi="10.17487/RFC7430", + } + +@misc{rfc7431, + author="A. Karan and C. Filsfils and IJ. {Wijnands (Ed.)} and B. Decraene", + title="{Multicast-Only Fast Reroute}", + howpublished="RFC 7431 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7431", + pages="1--14", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7431.txt", + key="RFC 7431", + abstract={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).}, + doi="10.17487/RFC7431", + } + +@misc{rfc7432, + author="A. {Sajassi (Ed.)} and R. Aggarwal and N. Bitar and A. Isaac and J. Uttaro and J. Drake and W. Henderickx", + title="{BGP MPLS-Based Ethernet VPN}", + howpublished="RFC 7432 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7432", + pages="1--56", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7432.txt", + key="RFC 7432", + abstract={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)''.}, + doi="10.17487/RFC7432", + } + +@misc{rfc7433, + author="A. Johnston and J. Rafferty", + title="{A Mechanism for Transporting User-to-User Call Control Information in SIP}", + howpublished="RFC 7433 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7433", + pages="1--19", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7433.txt", + key="RFC 7433", + abstract={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.}, + keywords="UUI, Package, Content, Encoding, Media", + doi="10.17487/RFC7433", + } + +@misc{rfc7434, + author="K. {Drage (Ed.)} and A. Johnston", + title="{Interworking ISDN Call Control User Information with SIP}", + howpublished="RFC 7434 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7434", + pages="1--17", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7434.txt", + key="RFC 7434", + abstract={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. This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by the new value ``isdn-uui'' of the ``purpose'' header field parameter.}, + keywords="UUS Supplementary Service", + doi="10.17487/RFC7434", + } + +@misc{rfc7435, + author="V. Dukhovni", + title="{Opportunistic Security: Some Protection Most of the Time}", + howpublished="RFC 7435 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7435", + pages="1--11", + year=2014, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7435.txt", + key="RFC 7435", + abstract={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.}, + keywords="authentication, encryption", + doi="10.17487/RFC7435", + } + +@misc{rfc7436, + author="H. Shah and E. Rosen and F. Le Faucheur and G. Heron", + title="{IP-Only LAN Service (IPLS)}", + howpublished="RFC 7436 (Historic)", + series="Internet Request for Comments", + type="RFC", + number="7436", + pages="1--32", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7436.txt", + key="RFC 7436", + abstract={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. 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.}, + doi="10.17487/RFC7436", + } + +@misc{rfc7437, + author="M. {Kucherawy (Ed.)}", + title="{IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees}", + howpublished="RFC 7437 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7437", + pages="1--35", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFCs 7776, 8318", +url="https://www.rfc-editor.org/rfc/rfc7437.txt", + key="RFC 7437", + abstract={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.}, + keywords="Internet Architecture Board, Engineering Steering Group, nomcom, IAOC", + doi="10.17487/RFC7437", + } + +@misc{rfc7438, + author="IJ. {Wijnands (Ed.)} and E. Rosen and A. Gulko and U. Joorde and J. Tantsura", + title="{Multipoint LDP (mLDP) In-Band Signaling with Wildcards}", + howpublished="RFC 7438 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7438", + pages="1--16", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7438.txt", + key="RFC 7438", + abstract={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.}, + keywords="mpls, multicast", + doi="10.17487/RFC7438", + } + +@misc{rfc7439, + author="W. {George (Ed.)} and C. {Pignataro (Ed.)}", + title="{Gap Analysis for Operating IPv6-Only MPLS Networks}", + howpublished="RFC 7439 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7439", + pages="1--28", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7439.txt", + key="RFC 7439", + abstract={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. 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.}, + keywords="MPLS, LDP, IPv6, RSVP, L3VPN, L2VPN", + doi="10.17487/RFC7439", + } + +@misc{rfc7440, + author="P. Masotta", + title="{TFTP Windowsize Option}", + howpublished="RFC 7440 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7440", + pages="1--9", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7440.txt", + key="RFC 7440", + abstract={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. 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).}, + doi="10.17487/RFC7440", + } + +@misc{rfc7441, + author="IJ. Wijnands and E. Rosen and U. Joorde", + title="{Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes}", + howpublished="RFC 7441 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7441", + pages="1--10", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7441.txt", + key="RFC 7441", + abstract={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.}, + doi="10.17487/RFC7441", + } + +@misc{rfc7442, + author="Y. Rekhter and R. Aggarwal and N. Leymann and W. Henderickx and Q. Zhao and R. Li", + title="{Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)}", + howpublished="RFC 7442 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7442", + pages="1--11", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7442.txt", + key="RFC 7442", + abstract={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).}, + doi="10.17487/RFC7442", + } + +@misc{rfc7443, + author="P. Patil and T. Reddy and G. Salgueiro and M. Petit-Huguenin", + title="{Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages}", + howpublished="RFC 7443 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7443", + pages="1--5", + year=2015, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7443.txt", + key="RFC 7443", + abstract={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).}, + doi="10.17487/RFC7443", + } + +@misc{rfc7444, + author="K. Zeilenga and A. Melnikov", + title="{Security Labels in Internet Email}", + howpublished="RFC 7444 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7444", + pages="1--16", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7444.txt", + key="RFC 7444", + abstract={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.}, + keywords="email, header fields, ESS, Security Label, Confidential Label, Message Sensitivity", + doi="10.17487/RFC7444", + } + +@misc{rfc7445, + author="G. Chen and H. Deng and D. Michaud and J. Korhonen and M. Boucadair", + title="{Analysis of Failure Cases in IPv6 Roaming Scenarios}", + howpublished="RFC 7445 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7445", + pages="1--19", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7445.txt", + key="RFC 7445", + abstract={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.}, + keywords="Mobile Network, Dual Stack, IPv6-only", + doi="10.17487/RFC7445", + } + +@misc{rfc7446, + author="Y. {Lee (Ed.)} and G. {Bernstein (Ed.)} and D. Li and W. Imajuku", + title="{Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks}", + howpublished="RFC 7446 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7446", + pages="1--23", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7446.txt", + key="RFC 7446", + abstract={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.}, + keywords="WSON, RWA", + doi="10.17487/RFC7446", + } + +@misc{rfc7447, + author="J. Scudder and K. Kompella", + title="{Deprecation of BGP Entropy Label Capability Attribute}", + howpublished="RFC 7447 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7447", + pages="1--4", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7447.txt", + key="RFC 7447", + abstract={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.}, + doi="10.17487/RFC7447", + } + +@misc{rfc7448, + author="T. {Taylor (Ed.)} and D. Romascanu", + title="{MIB Transfer from the IETF to the IEEE 802.3 WG}", + howpublished="RFC 7448 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7448", + pages="1--7", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7448.txt", + key="RFC 7448", + abstract={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.}, + keywords="Ethernet, IEEE", + doi="10.17487/RFC7448", + } + +@misc{rfc7449, + author="Y. {Lee (Ed.)} and G. {Bernstein (Ed.)} and J. Martensson and T. Takeda and T. Tsuritani and O. Gonzalez de Dios", + title="{Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment}", + howpublished="RFC 7449 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7449", + pages="1--12", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7449.txt", + key="RFC 7449", + abstract={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.}, + doi="10.17487/RFC7449", + } + +@misc{rfc7450, + author="G. Bumgardner", + title="{Automatic Multicast Tunneling}", + howpublished="RFC 7450 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7450", + pages="1--82", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7450.txt", + key="RFC 7450", + abstract={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. The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.}, + keywords="AMT, IGMPv2, IGMPv3, MLDv1, MLDv2, ASM, SSM, amt gateway, amt relay, multicast replication, multicast encapsulation", + doi="10.17487/RFC7450", + } + +@misc{rfc7451, + author="S. Hollenbeck", + title="{Extension Registry for the Extensible Provisioning Protocol}", + howpublished="RFC 7451 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7451", + pages="1--12", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7451.txt", + key="RFC 7451", + abstract={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.}, + keywords="domain, host, contact", + doi="10.17487/RFC7451", + } + +@misc{rfc7452, + author="H. Tschofenig and J. Arkko and D. Thaler and D. McPherson", + title="{Architectural Considerations in Smart Object Networking}", + howpublished="RFC 7452 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7452", + pages="1--24", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7452.txt", + key="RFC 7452", + abstract={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. This document offers guidance to engineers designing Internet- connected smart objects.}, + keywords="IAB Statement, Smart Objects", + doi="10.17487/RFC7452", + } + +@misc{rfc7453, + author="V. Mahalingam and K. Sampath and S. Aldrin and T. Nadeau", + title="{MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB)}", + howpublished="RFC 7453 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7453", + pages="1--62", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7453.txt", + key="RFC 7453", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.}, + doi="10.17487/RFC7453", + } + +@misc{rfc7454, + author="J. Durand and I. Pepelnjak and G. Doering", + title="{BGP Operations and Security}", + howpublished="RFC 7454 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7454", + pages="1--26", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7454.txt", + key="RFC 7454", + abstract={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. 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.}, + doi="10.17487/RFC7454", + } + +@misc{rfc7455, + author="T. Senevirathne and N. Finn and S. Salam and D. Kumar and D. {Eastlake 3rd} and S. Aldrin and Y. Li", + title="{Transparent Interconnection of Lots of Links (TRILL): Fault Management}", + howpublished="RFC 7455 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7455", + pages="1--63", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7455.txt", + key="RFC 7455", + abstract={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.}, + keywords="Fault, Continuity, Connectivity, OAM, CFM, MEP, CCM", + doi="10.17487/RFC7455", + } + +@misc{rfc7456, + author="T. Mizrahi and T. Senevirathne and S. Salam and D. Kumar and D. {Eastlake 3rd}", + title="{Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)}", + howpublished="RFC 7456 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7456", + pages="1--32", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7456.txt", + key="RFC 7456", + abstract={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.}, + doi="10.17487/RFC7456", + } + +@misc{rfc7457, + author="Y. Sheffer and R. Holz and P. Saint-Andre", + title="{Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)}", + howpublished="RFC 7457 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7457", + pages="1--13", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7457.txt", + key="RFC 7457", + abstract={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).}, + keywords="Transport Layer Security, TLS, Datagram TLS, DTLS, Secure Sockets Layer, SSL, security attacks", + doi="10.17487/RFC7457", + } + +@misc{rfc7458, + author="R. Valmikam and R. Koodli", + title="{Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core}", + howpublished="RFC 7458 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7458", + pages="1--18", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7458.txt", + key="RFC 7458", + abstract={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. 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.}, + keywords="Mobile Networks, 3GPP, EAP, EPC, Handover, Identity, APN", + doi="10.17487/RFC7458", + } + +@misc{rfc7459, + author="M. Thomson and J. Winterbottom", + title="{Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)}", + howpublished="RFC 7459 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7459", + pages="1--39", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7459.txt", + key="RFC 7459", + abstract={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. 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.}, + doi="10.17487/RFC7459", + } + +@misc{rfc7460, + author="M. Chandramouli and B. Claise and B. Schoening and J. Quittek and T. Dietz", + title="{Monitoring and Control MIB for Power and Energy}", + howpublished="RFC 7460 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7460", + pages="1--69", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7460.txt", + key="RFC 7460", + abstract={This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.}, + keywords="management information base, IANAPowerStateSet-MIB, ENERGY-OBJECT-MIB, POWER-ATTRIBUTES-MIB", + doi="10.17487/RFC7460", + } + +@misc{rfc7461, + author="J. Parello and B. Claise and M. Chandramouli", + title="{Energy Object Context MIB}", + howpublished="RFC 7461 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7461", + pages="1--32", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7461.txt", + key="RFC 7461", + abstract={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.}, + keywords="management information base, ENERGY-OBJECT-CONTEXT-MIB, IANA-ENERGY-RELATION-MIB", + doi="10.17487/RFC7461", + } + +@misc{rfc7462, + author="L. {Liess (Ed.)} and R. Jesske and A. Johnston and D. Worley and P. Kyzivat", + title="{URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)}", + howpublished="RFC 7462 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7462", + pages="1--46", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7462.txt", + key="RFC 7462", + abstract={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. 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 allowin g 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.}, + doi="10.17487/RFC7462", + } + +@misc{rfc7463, + author="A. {Johnston (Ed.)} and M. {Soroushnejad (Ed.)} and V. Venkataramanan", + title="{Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)}", + howpublished="RFC 7463 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7463", + pages="1--72", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7463.txt", + key="RFC 7463", + abstract={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.}, + doi="10.17487/RFC7463", + } + +@misc{rfc7464, + author="N. Williams", + title="{JavaScript Object Notation (JSON) Text Sequences}", + howpublished="RFC 7464 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7464", + pages="1--8", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7464.txt", + key="RFC 7464", + abstract={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).}, + keywords="JSON, sequence, online, streaming, log file", + doi="10.17487/RFC7464", + } + +@misc{rfc7465, + author="A. Popov", + title="{Prohibiting RC4 Cipher Suites}", + howpublished="RFC 7465 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7465", + pages="1--6", + year=2015, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7465.txt", + key="RFC 7465", + abstract={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.}, + keywords="TLS, transport layer security", + doi="10.17487/RFC7465", + } + +@misc{rfc7466, + author="C. Dearlove and T. Clausen", + title="{An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)}", + howpublished="RFC 7466 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7466", + pages="1--9", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7466.txt", + key="RFC 7466", + abstract={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. 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. 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''.}, + keywords="MANET, NHDP, OLSRv2, link quality", + doi="10.17487/RFC7466", + } + +@misc{rfc7467, + author="A. Murdock", + title="{URN Namespace for the North Atlantic Treaty Organization (NATO)}", + howpublished="RFC 7467 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7467", + pages="1--8", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7467.txt", + key="RFC 7467", + abstract={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.}, + doi="10.17487/RFC7467", + } + +@misc{rfc7468, + author="S. Josefsson and S. Leonard", + title="{Textual Encodings of PKIX, PKCS, and CMS Structures}", + howpublished="RFC 7468 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7468", + pages="1--20", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7468.txt", + key="RFC 7468", + abstract={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.}, + doi="10.17487/RFC7468", + } + +@misc{rfc7469, + author="C. Evans and C. Palmer and R. Sleevi", + title="{Public Key Pinning Extension for HTTP}", + howpublished="RFC 7469 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7469", + pages="1--28", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7469.txt", + key="RFC 7469", + abstract={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.}, + keywords="pin", + doi="10.17487/RFC7469", + } + +@misc{rfc7470, + author="F. Zhang and A. Farrel", + title="{Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol}", + howpublished="RFC 7470 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7470", + pages="1--14", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7470.txt", + key="RFC 7470", + abstract={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. 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. 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.}, + doi="10.17487/RFC7470", + } + +@misc{rfc7471, + author="S. Giacalone and D. Ward and J. Drake and A. Atlas and S. Previdi", + title="{OSPF Traffic Engineering (TE) Metric Extensions}", + howpublished="RFC 7471 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7471", + pages="1--19", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7471.txt", + key="RFC 7471", + abstract={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. 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. 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.}, + doi="10.17487/RFC7471", + } + +@misc{rfc7472, + author="I. McDonald and M. Sweet", + title="{Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme}", + howpublished="RFC 7472 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7472", + pages="1--19", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7472.txt", + key="RFC 7472", + abstract={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. 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.}, + doi="10.17487/RFC7472", + } + +@misc{rfc7473, + author="K. Raza and S. Boutros", + title="{Controlling State Advertisements of Non-negotiated LDP Applications}", + howpublished="RFC 7473 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7473", + pages="1--15", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8223", +url="https://www.rfc-editor.org/rfc/rfc7473.txt", + key="RFC 7473", + abstract={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.}, + doi="10.17487/RFC7473", + } + +@misc{rfc7474, + author="M. Bhatia and S. Hartman and D. Zhang and A. {Lindem (Ed.)}", + title="{Security Extension for OSPFv2 When Using Manual Key Management}", + howpublished="RFC 7474 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7474", + pages="1--14", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7474.txt", + key="RFC 7474", + abstract={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. 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.}, + keywords="OSPF, cryptographic authentication, security, replay attacks", + doi="10.17487/RFC7474", + } + +@misc{rfc7475, + author="S. Dawkins", + title="{Increasing the Number of Area Directors in an IETF Area}", + howpublished="RFC 7475 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7475", + pages="1--5", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7475.txt", + key="RFC 7475", + abstract={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).}, + doi="10.17487/RFC7475", + } + +@misc{rfc7476, + author="K. {Pentikousis (Ed.)} and B. Ohlman and D. Corujo and G. Boggia and G. Tyson and E. Davies and A. Molinaro and S. Eum", + title="{Information-Centric Networking: Baseline Scenarios}", + howpublished="RFC 7476 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7476", + pages="1--45", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7476.txt", + key="RFC 7476", + abstract={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. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).}, + doi="10.17487/RFC7476", + } + +@misc{rfc7477, + author="W. Hardaker", + title="{Child-to-Parent Synchronization in DNS}", + howpublished="RFC 7477 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7477", + pages="1--15", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7477.txt", + key="RFC 7477", + abstract={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.}, + doi="10.17487/RFC7477", + } + +@misc{rfc7478, + author="C. Holmberg and S. Hakansson and G. Eriksson", + title="{Web Real-Time Communication Use Cases and Requirements}", + howpublished="RFC 7478 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7478", + pages="1--28", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7478.txt", + key="RFC 7478", + abstract={This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases. 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.}, + keywords="webrtc, browser, websocket, real-time", + doi="10.17487/RFC7478", + } + +@misc{rfc7479, + author="S. Moonesamy", + title="{Using Ed25519 in SSHFP Resource Records}", + howpublished="RFC 7479 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7479", + pages="1--4", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7479.txt", + key="RFC 7479", + abstract={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.}, + doi="10.17487/RFC7479", + } + +@misc{rfc7480, + author="A. Newton and B. Ellacott and N. Kong", + title="{HTTP Usage in the Registration Data Access Protocol (RDAP)}", + howpublished="RFC 7480 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7480", + pages="1--16", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7480.txt", + key="RFC 7480", + abstract={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.}, + keywords="Registry, WHOIS", + doi="10.17487/RFC7480", + } + +@misc{rfc7481, + author="S. Hollenbeck and N. Kong", + title="{Security Services for the Registration Data Access Protocol (RDAP)}", + howpublished="RFC 7481 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7481", + pages="1--13", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7481.txt", + key="RFC 7481", + abstract={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.}, + keywords="RDAP, Security", + doi="10.17487/RFC7481", + } + +@misc{rfc7482, + author="A. Newton and S. Hollenbeck", + title="{Registration Data Access Protocol (RDAP) Query Format}", + howpublished="RFC 7482 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7482", + pages="1--20", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7482.txt", + key="RFC 7482", + abstract={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).}, + keywords="WHOIS", + doi="10.17487/RFC7482", + } + +@misc{rfc7483, + author="A. Newton and S. Hollenbeck", + title="{JSON Responses for the Registration Data Access Protocol (RDAP)}", + howpublished="RFC 7483 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7483", + pages="1--78", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7483.txt", + key="RFC 7483", + abstract={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.}, + keywords="WHOIS", + doi="10.17487/RFC7483", + } + +@misc{rfc7484, + author="M. Blanchet", + title="{Finding the Authoritative Registration Data (RDAP) Service}", + howpublished="RFC 7484 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7484", + pages="1--17", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7484.txt", + key="RFC 7484", + abstract={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.}, + keywords="whois, bootstrap, IDN, AS, IPv4, IPv6, JSON", + doi="10.17487/RFC7484", + } + +@misc{rfc7485, + author="L. Zhou and N. Kong and S. Shen and S. Sheng and A. Servin", + title="{Inventory and Analysis of WHOIS Registration Objects}", + howpublished="RFC 7485 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7485", + pages="1--33", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7485.txt", + key="RFC 7485", + abstract={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.}, + keywords="whois, restful, weirds, response object, inventory", + doi="10.17487/RFC7485", + } + +@misc{rfc7486, + author="S. Farrell and P. Hoffman and M. Thomas", + title="{HTTP Origin-Bound Authentication (HOBA)}", + howpublished="RFC 7486 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7486", + pages="1--28", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7486.txt", + key="RFC 7486", + abstract={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.}, + keywords="Network Working Group, http authentication, origin-bound key", + doi="10.17487/RFC7486", + } + +@misc{rfc7487, + author="E. Bellagamba and A. Takacs and G. Mirsky and L. Andersson and P. Skoldstrom and D. Ward", + title="{Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE}", + howpublished="RFC 7487 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7487", + pages="1--32", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7487.txt", + key="RFC 7487", + abstract={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.}, + keywords="RSVP-TE, GMPLS, MPLS, MPLS-TP, OAM", + doi="10.17487/RFC7487", + } + +@misc{rfc7488, + author="M. Boucadair and R. Penno and D. Wing and P. Patil and T. Reddy", + title="{Port Control Protocol (PCP) Server Selection}", + howpublished="RFC 7488 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7488", + pages="1--12", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7488.txt", + key="RFC 7488", + abstract={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. This document updates RFC 6887.}, + keywords="PCP Server discovery, Port Mapping, Shared Address, Multiple PCP Servers", + doi="10.17487/RFC7488", + } + +@misc{rfc7489, + author="M. {Kucherawy (Ed.)} and E. {Zwicky (Ed.)}", + title="{Domain-based Message Authentication, Reporting, and Conformance (DMARC)}", + howpublished="RFC 7489 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7489", + pages="1--73", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7489.txt", + key="RFC 7489", + abstract={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. 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. 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 f ail authentication checks, ranging from no action, through altered delivery, up to message rejection.}, + keywords="domain, email, security, messaging, dkim, spf, authentication, reporting, conformance", + doi="10.17487/RFC7489", + } + +@misc{rfc7490, + author="S. Bryant and C. Filsfils and S. Previdi and M. Shand and N. So", + title="{Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)}", + howpublished="RFC 7490 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7490", + pages="1--29", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7490.txt", + key="RFC 7490", + abstract={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.}, + doi="10.17487/RFC7490", + } + +@misc{rfc7491, + author="D. King and A. Farrel", + title="{A PCE-Based Architecture for Application-Based Network Operations}", + howpublished="RFC 7491 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7491", + pages="1--71", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7491.txt", + key="RFC 7491", + abstract={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. 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.}, + keywords="Software-Defined Networking (SDN), Path Computation Element (PCE), Network management, Network programming", + doi="10.17487/RFC7491", + } + +@misc{rfc7492, + author="M. Bhatia and D. Zhang and M. Jethanandani", + title="{Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines}", + howpublished="RFC 7492 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7492", + pages="1--9", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7492.txt", + key="RFC 7492", + abstract={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''.}, + keywords="BFD, KARP, replay attacks, cryptographic authentication, security, DoS attacks", + doi="10.17487/RFC7492", + } + +@misc{rfc7493, + author="T. {Bray (Ed.)}", + title="{The I-JSON Message Format}", + howpublished="RFC 7493 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7493", + pages="1--6", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7493.txt", + key="RFC 7493", + abstract={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.}, + keywords="JSON, Internet JSON", + doi="10.17487/RFC7493", + } + +@misc{rfc7494, + author="C. Shao and H. Deng and R. Pazhyannur and F. Bari and R. Zhang and S. Matsushima", + title="{IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP)}", + howpublished="RFC 7494 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7494", + pages="1--13", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7494.txt", + key="RFC 7494", + abstract={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.}, + keywords="CAPWAP, MAC Profile, Encryption, IEEE 802.11", + doi="10.17487/RFC7494", + } + +@misc{rfc7495, + author="A. Montville and D. Black", + title="{Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)}", + howpublished="RFC 7495 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7495", + pages="1--10", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7495.txt", + key="RFC 7495", + abstract={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. 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 i s applicable to other formats that support this class of enumeration references.}, + keywords="IODEF, Incident, Reference, Enumeration, Format", + doi="10.17487/RFC7495", + } + +@misc{rfc7496, + author="M. Tuexen and R. Seggelmann and R. Stewart and S. Loreto", + title="{Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension}", + howpublished="RFC 7496 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7496", + pages="1--11", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7496.txt", + key="RFC 7496", + abstract={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.}, + doi="10.17487/RFC7496", + } + +@misc{rfc7497, + author="A. Morton", + title="{Rate Measurement Test Protocol Problem Statement and Requirements}", + howpublished="RFC 7497 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7497", + pages="1--14", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7497.txt", + key="RFC 7497", + abstract={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.}, + keywords="Internet access, Asymmetric Packet Size", + doi="10.17487/RFC7497", + } + +@misc{rfc7498, + author="P. {Quinn (Ed.)} and T. {Nadeau (Ed.)}", + title="{Problem Statement for Service Function Chaining}", + howpublished="RFC 7498 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7498", + pages="1--13", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7498.txt", + key="RFC 7498", + abstract={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. The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy. 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.}, + keywords="service function chaining, steering, sfc", + doi="10.17487/RFC7498", + } + +@misc{rfc7499, + author="A. {Perez-Mendez (Ed.)} and R. Marin-Lopez and F. Pereniguez-Garcia and G. Lopez-Millan and D. Lopez and A. DeKok", + title="{Support of Fragmentation of RADIUS Packets}", + howpublished="RFC 7499 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7499", + pages="1--38", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7499.txt", + key="RFC 7499", + abstract={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.}, + keywords="RADIUS, attribute, extension, fragmentation, chunk", + doi="10.17487/RFC7499", + } + +@misc{rfc7500, + author="R. {Housley (Ed.)} and O. {Kolkman (Ed.)}", + title="{Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries}", + howpublished="RFC 7500 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7500", + pages="1--7", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7500.txt", + key="RFC 7500", + abstract={This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.}, + doi="10.17487/RFC7500", + } + +@misc{rfc7501, + author="C. Davids and V. Gurbani and S. Poretsky", + title="{Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration}", + howpublished="RFC 7501 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7501", + pages="1--20", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7501.txt", + key="RFC 7501", + abstract={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 be nchmarks have consistent definitions and were obtained following the same procedures.}, + doi="10.17487/RFC7501", + } + +@misc{rfc7502, + author="C. Davids and V. Gurbani and S. Poretsky", + title="{Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration}", + howpublished="RFC 7502 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7502", + pages="1--21", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7502.txt", + key="RFC 7502", + abstract={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.}, + doi="10.17487/RFC7502", + } + +@misc{rfc7503, + author="A. Lindem and J. Arkko", + title="{OSPFv3 Autoconfiguration}", + howpublished="RFC 7503 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7503", + pages="1--15", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7503.txt", + key="RFC 7503", + abstract={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).}, + doi="10.17487/RFC7503", + } + +@misc{rfc7504, + author="J. Klensin", + title="{SMTP 521 and 556 Reply Codes}", + howpublished="RFC 7504 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7504", + pages="1--7", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7504.txt", + key="RFC 7504", + abstract={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.}, + keywords="Reply code, Email, Server, No Mail", + doi="10.17487/RFC7504", + } + +@misc{rfc7505, + author="J. Levine and M. Delany", + title="{A ``Null MX'' No Service Resource Record for Domains That Accept No Mail}", + howpublished="RFC 7505 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7505", + pages="1--6", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7505.txt", + key="RFC 7505", + abstract={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.}, + keywords="DNS, e-mail", + doi="10.17487/RFC7505", + } + +@misc{rfc7506, + author="K. Raza and N. Akiya and C. Pignataro", + title="{IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)}", + howpublished="RFC 7506 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7506", + pages="1--6", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7506.txt", + key="RFC 7506", + abstract={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. 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.}, + keywords="IPv6, LSP Ping, MPLS OAM", + doi="10.17487/RFC7506", + } + +@misc{rfc7507, + author="B. Moeller and A. Langley", + title="{TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks}", + howpublished="RFC 7507 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7507", + pages="1--8", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7507.txt", + key="RFC 7507", + abstract={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.}, + doi="10.17487/RFC7507", + } + +@misc{rfc7508, + author="L. Cailleux and C. Bonatti", + title="{Securing Header Fields with S/MIME}", + howpublished="RFC 7508 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7508", + pages="1--19", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7508.txt", + key="RFC 7508", + abstract={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'.}, + keywords="secure headers", + doi="10.17487/RFC7508", + } + +@misc{rfc7509, + author="R. Huang and V. Singh", + title="{RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics}", + howpublished="RFC 7509 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7509", + pages="1--11", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7509.txt", + key="RFC 7509", + abstract={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.}, + doi="10.17487/RFC7509", + } + +@misc{rfc7510, + author="X. Xu and N. Sheth and L. Yong and R. Callon and D. Black", + title="{Encapsulating MPLS in UDP}", + howpublished="RFC 7510 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7510", + pages="1--19", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7510.txt", + key="RFC 7510", + abstract={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.}, + keywords="MPLS, UDP, Tunnel, Checksum, encapsulation, multipath, ECMP", + doi="10.17487/RFC7510", + } + +@misc{rfc7511, + author="M. Wilhelm", + title="{Scenic Routing for IPv6}", + howpublished="RFC 7511 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7511", + pages="1--8", + year=2015, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7511.txt", + key="RFC 7511", + abstract={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.}, + keywords="green it", + doi="10.17487/RFC7511", + } + +@misc{rfc7512, + author="J. Pechanec and D. Moffat", + title="{The PKCS \#11 URI Scheme}", + howpublished="RFC 7512 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7512", + pages="1--20", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7512.txt", + key="RFC 7512", + abstract={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''.}, + keywords="PKCS11, PKCS-11, PKCS\#11,", + doi="10.17487/RFC7512", + } + +@misc{rfc7513, + author="J. Bi and J. Wu and G. Yao and F. Baker", + title="{Source Address Validation Improvement (SAVI) Solution for DHCP}", + howpublished="RFC 7513 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7513", + pages="1--54", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7513.txt", + key="RFC 7513", + abstract={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.}, + keywords="SAVI-DHCP", + doi="10.17487/RFC7513", + } + +@misc{rfc7514, + author="M. Luckie", + title="{Really Explicit Congestion Notification (RECN)}", + howpublished="RFC 7514 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7514", + pages="1--5", + year=2015, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7514.txt", + key="RFC 7514", + abstract={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).}, + doi="10.17487/RFC7514", + } + +@misc{rfc7515, + author="M. Jones and J. Bradley and N. Sakimura", + title="{JSON Web Signature (JWS)}", + howpublished="RFC 7515 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7515", + pages="1--59", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7515.txt", + key="RFC 7515", + abstract={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.}, + keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA", + doi="10.17487/RFC7515", + } + +@misc{rfc7516, + author="M. Jones and J. Hildebrand", + title="{JSON Web Encryption (JWE)}", + howpublished="RFC 7516 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7516", + pages="1--51", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7516.txt", + key="RFC 7516", + abstract={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.}, + keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA", + doi="10.17487/RFC7516", + } + +@misc{rfc7517, + author="M. Jones", + title="{JSON Web Key (JWK)}", + howpublished="RFC 7517 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7517", + pages="1--40", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7517.txt", + key="RFC 7517", + abstract={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.}, + keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA", + doi="10.17487/RFC7517", + } + +@misc{rfc7518, + author="M. Jones", + title="{JSON Web Algorithms (JWA)}", + howpublished="RFC 7518 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7518", + pages="1--69", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7518.txt", + key="RFC 7518", + abstract={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.}, + doi="10.17487/RFC7518", + } + +@misc{rfc7519, + author="M. Jones and J. Bradley and N. Sakimura", + title="{JSON Web Token (JWT)}", + howpublished="RFC 7519 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7519", + pages="1--30", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7797", +url="https://www.rfc-editor.org/rfc/rfc7519.txt", + key="RFC 7519", + abstract={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.}, + keywords="Assertion, Claim, Security Token, JavaScript Object Notation, JSON, JSON Web Token, JWT, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA", + doi="10.17487/RFC7519", + } + +@misc{rfc7520, + author="M. Miller", + title="{Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)}", + howpublished="RFC 7520 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7520", + pages="1--120", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7520.txt", + key="RFC 7520", + abstract={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.}, + keywords="JSON Object Signing and Encryption, JOSE, JavaScript Object Notation, JSON, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA, Cookbook", + doi="10.17487/RFC7520", + } + +@misc{rfc7521, + author="B. Campbell and C. Mortimore and M. Jones and Y. Goland", + title="{Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants}", + howpublished="RFC 7521 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7521", + pages="1--20", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7521.txt", + key="RFC 7521", + abstract={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. 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. 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.}, + keywords="OAuth, SAML, JWT, Assertion", + doi="10.17487/RFC7521", + } + +@misc{rfc7522, + author="B. Campbell and C. Mortimore and M. Jones", + title="{Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants}", + howpublished="RFC 7522 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7522", + pages="1--15", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7522.txt", + key="RFC 7522", + abstract={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.}, + keywords="OAuth, SAML, Assertion", + doi="10.17487/RFC7522", + } + +@misc{rfc7523, + author="M. Jones and B. Campbell and C. Mortimore", + title="{JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants}", + howpublished="RFC 7523 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7523", + pages="1--12", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7523.txt", + key="RFC 7523", + abstract={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.}, + keywords="OAuth, JWT, Assertion, Token, Security Token", + doi="10.17487/RFC7523", + } + +@misc{rfc7524, + author="Y. Rekhter and E. Rosen and R. Aggarwal and T. Morin and I. Grosclaude and N. Leymann and S. Saad", + title="{Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)}", + howpublished="RFC 7524 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7524", + pages="1--42", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7524.txt", + key="RFC 7524", + abstract={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.}, + doi="10.17487/RFC7524", + } + +@misc{rfc7525, + author="Y. Sheffer and R. Holz and P. Saint-Andre", + title="{Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 7525 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7525", + pages="1--27", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7525.txt", + key="RFC 7525", + abstract={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.}, + keywords="Transport Layer Security, TLS, DTLS, Secure Sockets Layer, SSL", + doi="10.17487/RFC7525", + } + +@misc{rfc7526, + author="O. Troan and B. {Carpenter (Ed.)}", + title="{Deprecating the Anycast Prefix for 6to4 Relay Routers}", + howpublished="RFC 7526 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7526", + pages="1--10", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7526.txt", + key="RFC 7526", + abstract={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.}, + doi="10.17487/RFC7526", + } + +@misc{rfc7527, + author="R. Asati and H. Singh and W. Beebee and C. Pignataro and E. Dart and W. George", + title="{Enhanced Duplicate Address Detection}", + howpublished="RFC 7527 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7527", + pages="1--11", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7527.txt", + key="RFC 7527", + abstract={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.}, + keywords="Automated DAD, loopback detection", + doi="10.17487/RFC7527", + } + +@misc{rfc7528, + author="P. Higgs and J. Piesing", + title="{A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association}", + howpublished="RFC 7528 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7528", + pages="1--7", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7528.txt", + key="RFC 7528", + abstract={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.}, + doi="10.17487/RFC7528", + } + +@misc{rfc7529, + author="C. Daboo and G. Yakushev", + title="{Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)}", + howpublished="RFC 7529 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7529", + pages="1--21", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7529.txt", + key="RFC 7529", + abstract={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.}, + keywords="calendaring, iCalendar, iTIP, CalDAV", + doi="10.17487/RFC7529", + } + +@misc{rfc7530, + author="T. {Haynes (Ed.)} and D. {Noveck (Ed.)}", + title="{Network File System (NFS) Version 4 Protocol}", + howpublished="RFC 7530 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7530", + pages="1--323", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7931", +url="https://www.rfc-editor.org/rfc/rfc7530.txt", + key="RFC 7530", + abstract={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. 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.}, + doi="10.17487/RFC7530", + } + +@misc{rfc7531, + author="T. {Haynes (Ed.)} and D. {Noveck (Ed.)}", + title="{Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description}", + howpublished="RFC 7531 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7531", + pages="1--39", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7531.txt", + key="RFC 7531", + abstract={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. RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.}, + doi="10.17487/RFC7531", + } + +@misc{rfc7532, + author="J. Lentini and R. Tewari and C. {Lever (Ed.)}", + title="{Namespace Database (NSDB) Protocol for Federated File Systems}", + howpublished="RFC 7532 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7532", + pages="1--65", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7532.txt", + key="RFC 7532", + abstract={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.}, + keywords="Federated File Systems", + doi="10.17487/RFC7532", + } + +@misc{rfc7533, + author="J. Lentini and R. Tewari and C. {Lever (Ed.)}", + title="{Administration Protocol for Federated File Systems}", + howpublished="RFC 7533 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7533", + pages="1--37", + year=2015, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7533.txt", + key="RFC 7533", + abstract={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.}, + keywords="Federated File Systems", + doi="10.17487/RFC7533", + } + +@misc{rfc7534, + author="J. Abley and W. Sotomayor", + title="{AS112 Nameserver Operations}", + howpublished="RFC 7534 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7534", + pages="1--24", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7534.txt", + key="RFC 7534", + abstract={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. 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. 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. This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document obsoletes RFC 6304.}, + keywords="AS112, DNS, reverse DNS, anycast", + doi="10.17487/RFC7534", + } + +@misc{rfc7535, + author="J. Abley and B. Dickson and W. Kumari and G. Michaelson", + title="{AS112 Redirection Using DNAME}", + howpublished="RFC 7535 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7535", + pages="1--16", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7535.txt", + key="RFC 7535", + abstract={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. 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.}, + keywords="DNS, root server", + doi="10.17487/RFC7535", + } + +@misc{rfc7536, + author="M. Linsner and P. Eardley and T. Burbridge and F. Sorensen", + title="{Large-Scale Broadband Measurement Use Cases}", + howpublished="RFC 7536 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7536", + pages="1--17", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7536.txt", + key="RFC 7536", + abstract={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.}, + keywords="lmap", + doi="10.17487/RFC7536", + } + +@misc{rfc7537, + author="B. Decraene and N. Akiya and C. Pignataro and L. Andersson and S. Aldrin", + title="{IANA Registries for LSP Ping Code Points}", + howpublished="RFC 7537 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7537", + pages="1--7", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8029", +url="https://www.rfc-editor.org/rfc/rfc7537.txt", + key="RFC 7537", + abstract={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. 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.}, + keywords="MPLS OAM, lsp ping, LSP-Ping", + doi="10.17487/RFC7537", + } + +@misc{rfc7538, + author="J. Reschke", + title="{The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)}", + howpublished="RFC 7538 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7538", + pages="1--6", + year=2015, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7538.txt", + key="RFC 7538", + abstract={This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).}, + keywords="HTTP, redirect, status code", + doi="10.17487/RFC7538", + } + +@misc{rfc7539, + author="Y. Nir and A. Langley", + title="{ChaCha20 and Poly1305 for IETF Protocols}", + howpublished="RFC 7539 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7539", + pages="1--45", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8439", +url="https://www.rfc-editor.org/rfc/rfc7539.txt", + key="RFC 7539", + abstract={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. 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).}, + keywords="AEAD", + doi="10.17487/RFC7539", + } + +@misc{rfc7540, + author="M. Belshe and R. Peon and M. {Thomson (Ed.)}", + title="{Hypertext Transfer Protocol Version 2 (HTTP/2)}", + howpublished="RFC 7540 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7540", + pages="1--96", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7540.txt", + key="RFC 7540", + abstract={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. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.}, + keywords="HTTP, SPDY, Web", + doi="10.17487/RFC7540", + } + +@misc{rfc7541, + author="R. Peon and H. Ruellan", + title="{HPACK: Header Compression for HTTP/2}", + howpublished="RFC 7541 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7541", + pages="1--55", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7541.txt", + key="RFC 7541", + abstract={This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.}, + keywords="HTTP, Header", + doi="10.17487/RFC7541", + } + +@misc{rfc7542, + author="A. DeKok", + title="{The Network Access Identifier}", + howpublished="RFC 7542 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7542", + pages="1--30", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7542.txt", + key="RFC 7542", + abstract={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.}, + doi="10.17487/RFC7542", + } + +@misc{rfc7543, + author="H. Jeng and L. Jalil and R. Bonica and K. Patel and L. Yong", + title="{Covering Prefixes Outbound Route Filter for BGP-4}", + howpublished="RFC 7543 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7543", + pages="1--21", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7543.txt", + key="RFC 7543", + abstract={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.}, + keywords="ORF, VPN", + doi="10.17487/RFC7543", + } + +@misc{rfc7544, + author="M. Mohali", + title="{Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)}", + howpublished="RFC 7544 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7544", + pages="1--30", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7544.txt", + key="RFC 7544", + abstract={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. RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests. 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. 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.}, + keywords="Diversion, History-Info", + doi="10.17487/RFC7544", + } + +@misc{rfc7545, + author="V. {Chen (Ed.)} and S. Das and L. Zhu and J. Malyar and P. McCann", + title="{Protocol to Access White-Space (PAWS) Databases}", + howpublished="RFC 7545 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7545", + pages="1--90", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7545.txt", + key="RFC 7545", + abstract={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. 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''.}, + keywords="dynamic spectrum, radio spectrum, wireless spectrum, spectrum, spectrum database, TV white space, TVWS, TVBD, white space device, WSD", + doi="10.17487/RFC7545", + } + +@misc{rfc7546, + author="B. Kaduk", + title="{Structure of the Generic Security Service (GSS) Negotiation Loop}", + howpublished="RFC 7546 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7546", + pages="1--21", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7546.txt", + key="RFC 7546", + abstract={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.}, + keywords="GSS-API, security, authentication", + doi="10.17487/RFC7546", + } + +@misc{rfc7547, + author="M. {Ersue (Ed.)} and D. Romascanu and J. Schoenwaelder and U. Herberg", + title="{Management of Networks with Constrained Devices: Problem Statement and Requirements}", + howpublished="RFC 7547 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7547", + pages="1--44", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7547.txt", + key="RFC 7547", + abstract={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.}, + keywords="Constrained, Management, IoT, M2M", + doi="10.17487/RFC7547", + } + +@misc{rfc7548, + author="M. {Ersue (Ed.)} and D. Romascanu and J. Schoenwaelder and A. Sehgal", + title="{Management of Networks with Constrained Devices: Use Cases}", + howpublished="RFC 7548 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7548", + pages="1--26", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7548.txt", + key="RFC 7548", + abstract={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).}, + keywords="Constrained, Management, IoT, M2M", + doi="10.17487/RFC7548", + } + +@misc{rfc7549, + author="C. Holmberg and J. Holm and R. Jesske and M. Dolly", + title="{3GPP SIP URI Inter-Operator Traffic Leg Parameter}", + howpublished="RFC 7549 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7549", + pages="1--17", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7549.txt", + key="RFC 7549", + abstract={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. 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).}, + keywords="3GPP, IMS, NNI, IOTL, CSCF, RAVEL, TRF, operator, transit", + doi="10.17487/RFC7549", + } + +@misc{rfc7550, + author="O. Troan and B. Volz and M. Siodelski", + title="{Issues and Recommendations with Multiple Stateful DHCPv6 Options}", + howpublished="RFC 7550 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7550", + pages="1--24", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7550.txt", + key="RFC 7550", + abstract={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.}, + keywords="CPE, CER, CE, Customer Edge Router, Prefix Delegation, IPv6 Address Option, Session, State Machine, Advertise, Time, Timer T1 T2, Renew, Rebind, Confirm, Decline, Provision", + doi="10.17487/RFC7550", + } + +@misc{rfc7551, + author="F. {Zhang (Ed.)} and R. Jing and R. {Gandhi (Ed.)}", + title="{RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)}", + howpublished="RFC 7551 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7551", + pages="1--20", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7551.txt", + key="RFC 7551", + abstract={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.}, + doi="10.17487/RFC7551", + } + +@misc{rfc7552, + author="R. Asati and C. Pignataro and K. Raza and V. Manral and R. Papneja", + title="{Updates to LDP for IPv6}", + howpublished="RFC 7552 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7552", + pages="1--24", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7552.txt", + key="RFC 7552", + abstract={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.}, + keywords="Label Distribution Protocol", + doi="10.17487/RFC7552", + } + +@misc{rfc7553, + author="P. Faltstrom and O. Kolkman", + title="{The Uniform Resource Identifier (URI) DNS Resource Record}", + howpublished="RFC 7553 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7553", + pages="1--14", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7553.txt", + key="RFC 7553", + abstract={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.}, + keywords="Operations, DNS, applications", + doi="10.17487/RFC7553", + } + +@misc{rfc7554, + author="T. {Watteyne (Ed.)} and M. Palattella and L. Grieco", + title="{Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement}", + howpublished="RFC 7554 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7554", + pages="1--23", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7554.txt", + key="RFC 7554", + abstract={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.}, + keywords="6TiSCH", + doi="10.17487/RFC7554", + } + +@misc{rfc7555, + author="G. Swallow and V. Lim and S. Aldrin", + title="{Proxy MPLS Echo Request}", + howpublished="RFC 7555 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7555", + pages="1--28", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7555.txt", + key="RFC 7555", + abstract={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).}, + doi="10.17487/RFC7555", + } + +@misc{rfc7556, + author="D. {Anipko (Ed.)}", + title="{Multiple Provisioning Domain Architecture}", + howpublished="RFC 7556 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7556", + pages="1--25", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7556.txt", + key="RFC 7556", + abstract={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.}, + doi="10.17487/RFC7556", + } + +@misc{rfc7557, + author="J. Chroboczek", + title="{Extension Mechanism for the Babel Routing Protocol}", + howpublished="RFC 7557 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7557", + pages="1--11", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7557.txt", + key="RFC 7557", + abstract={This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.}, + keywords="Babel, routing, extension, TLV, sub-TLV", + doi="10.17487/RFC7557", + } + +@misc{rfc7558, + author="K. Lynn and S. Cheshire and M. Blanchet and D. Migault", + title="{Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions}", + howpublished="RFC 7558 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7558", + pages="1--14", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7558.txt", + key="RFC 7558", + abstract={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.}, + doi="10.17487/RFC7558", + } + +@misc{rfc7559, + author="S. Krishnan and D. Anipko and D. Thaler", + title="{Packet-Loss Resiliency for Router Solicitations}", + howpublished="RFC 7559 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7559", + pages="1--6", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7559.txt", + key="RFC 7559", + abstract={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.}, + doi="10.17487/RFC7559", + } + +@misc{rfc7560, + author="M. {Kuehlewind (Ed.)} and R. Scheffenegger and B. Briscoe", + title="{Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback}", + howpublished="RFC 7560 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7560", + pages="1--17", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7560.txt", + key="RFC 7560", + abstract={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.}, + keywords="congestion control, TCP", + doi="10.17487/RFC7560", + } + +@misc{rfc7561, + author="J. Kaippallimalil and R. Pazhyannur and P. Yegani", + title="{Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN}", + howpublished="RFC 7561 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7561", + pages="1--23", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7561.txt", + key="RFC 7561", + abstract={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.}, + keywords="PMIPv6, Wi-Fi, QoS", + doi="10.17487/RFC7561", + } + +@misc{rfc7562, + author="D. Thakore", + title="{Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates}", + howpublished="RFC 7562 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7562", + pages="1--15", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7562.txt", + key="RFC 7562", + abstract={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).}, + keywords="Transport Layer Security, TLS, SupplementalData, DTCP", + doi="10.17487/RFC7562", + } + +@misc{rfc7563, + author="R. Pazhyannur and S. Speicher and S. Gundavelli and J. Korhonen and J. Kaippallimalil", + title="{Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option}", + howpublished="RFC 7563 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7563", + pages="1--12", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7563.txt", + key="RFC 7563", + abstract={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.}, + doi="10.17487/RFC7563", + } + +@misc{rfc7564, + author="P. Saint-Andre and M. Blanchet", + title="{PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols}", + howpublished="RFC 7564 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7564", + pages="1--40", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8264", +url="https://www.rfc-editor.org/rfc/rfc7564.txt", + key="RFC 7564", + abstract={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.}, + keywords="internationalization, i18n, Stringprep", + doi="10.17487/RFC7564", + } + +@misc{rfc7565, + author="P. Saint-Andre", + title="{The 'acct' URI Scheme}", + howpublished="RFC 7565 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7565", + pages="1--8", + year=2015, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7565.txt", + key="RFC 7565", + abstract={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.}, + keywords="Uniform Resource Identifier, URI", + doi="10.17487/RFC7565", + } + +@misc{rfc7566, + author="L. Goix and K. Li", + title="{Enumservice Registration for 'acct' URI}", + howpublished="RFC 7566 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7566", + pages="1--8", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7566.txt", + key="RFC 7566", + abstract={This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).}, + keywords="Reverse Phone Lookup, Social Network Web", + doi="10.17487/RFC7566", + } + +@misc{rfc7567, + author="F. {Baker (Ed.)} and G. {Fairhurst (Ed.)}", + title="{IETF Recommendations Regarding Active Queue Management}", + howpublished="RFC 7567 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7567", + pages="1--31", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7567.txt", + key="RFC 7567", + abstract={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. Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.}, + doi="10.17487/RFC7567", + } + +@misc{rfc7568, + author="R. Barnes and M. Thomson and A. Pironti and A. Langley", + title="{Deprecating Secure Sockets Layer Version 3.0}", + howpublished="RFC 7568 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7568", + pages="1--7", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7568.txt", + key="RFC 7568", + abstract={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. This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.}, + keywords="SSL, TLS, insecure, diediedie", + doi="10.17487/RFC7568", + } + +@misc{rfc7569, + author="D. Quigley and J. Lu and T. Haynes", + title="{Registry Specification for Mandatory Access Control (MAC) Security Label Formats}", + howpublished="RFC 7569 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7569", + pages="1--10", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7569.txt", + key="RFC 7569", + abstract={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. 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.}, + keywords="NFSv4", + doi="10.17487/RFC7569", + } + +@misc{rfc7570, + author="C. {Margaria (Ed.)} and G. Martinelli and S. Balls and B. Wright", + title="{Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)}", + howpublished="RFC 7570 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7570", + pages="1--15", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7570.txt", + key="RFC 7570", + abstract={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.}, + keywords="RSVP-TE, GMPLS", + doi="10.17487/RFC7570", + } + +@misc{rfc7571, + author="J. Dong and M. Chen and Z. Li and D. Ceccarelli", + title="{GMPLS RSVP-TE Extensions for Lock Instruct and Loopback}", + howpublished="RFC 7571 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7571", + pages="1--9", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7571.txt", + key="RFC 7571", + abstract={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.}, + keywords="OAM", + doi="10.17487/RFC7571", + } + +@misc{rfc7572, + author="P. Saint-Andre and A. Houri and J. Hildebrand", + title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging}", + howpublished="RFC 7572 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7572", + pages="1--13", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7572.txt", + key="RFC 7572", + abstract={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).}, + keywords="XMPP, Jabber, SIP, SIMPLE, IM, Instant Message", + doi="10.17487/RFC7572", + } + +@misc{rfc7573, + author="P. Saint-Andre and S. Loreto", + title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions}", + howpublished="RFC 7573 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7573", + pages="1--20", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7573.txt", + key="RFC 7573", + abstract={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).}, + keywords="Text Chat, Instant Messaging, Session Initiation Protocol, SIP, Message Sessions Relay Protocol, MSRP, Extensible Messaging and Presence Protocol, XMPP", + doi="10.17487/RFC7573", + } + +@misc{rfc7574, + author="A. Bakker and R. Petrocco and V. Grishchenko", + title="{Peer-to-Peer Streaming Peer Protocol (PPSPP)}", + howpublished="RFC 7574 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7574", + pages="1--85", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7574.txt", + key="RFC 7574", + abstract={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 t op of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.}, + keywords="video on demand, live streaming, content integrity protection", + doi="10.17487/RFC7574", + } + +@misc{rfc7575, + author="M. Behringer and M. Pritikin and S. Bjarnason and A. Clemm and B. Carpenter and S. Jiang and L. Ciavaglia", + title="{Autonomic Networking: Definitions and Design Goals}", + howpublished="RFC 7575 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7575", + pages="1--16", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7575.txt", + key="RFC 7575", + abstract={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. 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.}, + keywords="self-management, self-chop, autonomic, secure by default, simplification", + doi="10.17487/RFC7575", + } + +@misc{rfc7576, + author="S. Jiang and B. Carpenter and M. Behringer", + title="{General Gap Analysis for Autonomic Networking}", + howpublished="RFC 7576 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7576", + pages="1--17", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7576.txt", + key="RFC 7576", + abstract={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. This document is a product of the IRTF's Network Management Research Group.}, + doi="10.17487/RFC7576", + } + +@misc{rfc7577, + author="J. Quittek and R. Winter and T. Dietz", + title="{Definition of Managed Objects for Battery Monitoring}", + howpublished="RFC 7577 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7577", + pages="1--40", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7577.txt", + key="RFC 7577", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices.}, + keywords="Energy Management, Battery Status, Battery MIB, Management Information Base", + doi="10.17487/RFC7577", + } + +@misc{rfc7578, + author="L. Masinter", + title="{Returning Values from Forms: multipart/form-data}", + howpublished="RFC 7578 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7578", + pages="1--15", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7578.txt", + key="RFC 7578", + abstract={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.}, + keywords="media-type, multipurpose, internet, mail, extensions", + doi="10.17487/RFC7578", + } + +@misc{rfc7579, + author="G. {Bernstein (Ed.)} and Y. {Lee (Ed.)} and D. Li and W. Imajuku and J. Han", + title="{General Network Element Constraint Encoding for GMPLS-Controlled Networks}", + howpublished="RFC 7579 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7579", + pages="1--28", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7579.txt", + key="RFC 7579", + abstract={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. 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.}, + keywords="WSON, Optical Network Control, Protocol-agnostic encoding", + doi="10.17487/RFC7579", + } + +@misc{rfc7580, + author="F. Zhang and Y. Lee and J. Han and G. Bernstein and Y. Xu", + title="{OSPF-TE Extensions for General Network Element Constraints}", + howpublished="RFC 7580 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7580", + pages="1--12", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7580.txt", + key="RFC 7580", + abstract={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.}, + keywords="WSON, Optical Routing", + doi="10.17487/RFC7580", + } + +@misc{rfc7581, + author="G. {Bernstein (Ed.)} and Y. {Lee (Ed.)} and D. Li and W. Imajuku and J. Han", + title="{Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks}", + howpublished="RFC 7581 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7581", + pages="1--37", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7581.txt", + key="RFC 7581", + abstract={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. 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 Eleme nt (PCE).}, + keywords="Optical Networks, GMPLS control plane, Wavelength Assignment, Optical LSP, Optical Routing", + doi="10.17487/RFC7581", + } + +@misc{rfc7582, + author="E. Rosen and IJ. Wijnands and Y. Cai and A. Boers", + title="{Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels}", + howpublished="RFC 7582 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7582", + pages="1--34", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7582.txt", + key="RFC 7582", + abstract={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 d etermining which flows have been assigned to which tunnels.}, + doi="10.17487/RFC7582", + } + +@misc{rfc7583, + author="S. Morris and J. Ihren and J. Dickinson and W. Mekking", + title="{DNSSEC Key Rollover Timing Considerations}", + howpublished="RFC 7583 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7583", + pages="1--31", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7583.txt", + key="RFC 7583", + abstract={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.}, + doi="10.17487/RFC7583", + } + +@misc{rfc7584, + author="R. Ravindranath and T. Reddy and G. Salgueiro", + title="{Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)}", + howpublished="RFC 7584 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7584", + pages="1--14", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7584.txt", + key="RFC 7584", + abstract={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. 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.}, + doi="10.17487/RFC7584", + } + +@misc{rfc7585, + author="S. Winter and M. McCauley", + title="{Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)}", + howpublished="RFC 7585 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7585", + pages="1--32", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7585.txt", + key="RFC 7585", + abstract={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).}, + keywords="RADIUS, AAA, Security, Reliability, DNS", + doi="10.17487/RFC7585", + } + +@misc{rfc7586, + author="Y. Nachum and L. Dunbar and I. Yerushalmi and T. Mizrahi", + title="{The Scalable Address Resolution Protocol (SARP) for Large Data Centers}", + howpublished="RFC 7586 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7586", + pages="1--21", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7586.txt", + key="RFC 7586", + abstract={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.}, + keywords="ARP, data center, proxy", + doi="10.17487/RFC7586", + } + +@misc{rfc7587, + author="J. Spittka and K. Vos and JM. Valin", + title="{RTP Payload Format for the Opus Speech and Audio Codec}", + howpublished="RFC 7587 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7587", + pages="1--18", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7587.txt", + key="RFC 7587", + abstract={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.}, + keywords="audio codec", + doi="10.17487/RFC7587", + } + +@misc{rfc7588, + author="R. Bonica and C. Pignataro and J. Touch", + title="{A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem}", + howpublished="RFC 7588 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7588", + pages="1--12", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7588.txt", + key="RFC 7588", + abstract={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.}, + keywords="GRE, MTU, Fragmentation", + doi="10.17487/RFC7588", + } + +@misc{rfc7589, + author="M. Badra and A. Luchuk and J. Schoenwaelder", + title="{Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication}", + howpublished="RFC 7589 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7589", + pages="1--11", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7589.txt", + key="RFC 7589", + abstract={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.}, + keywords="NETCONF, TLS", + doi="10.17487/RFC7589", + } + +@misc{rfc7590, + author="P. Saint-Andre and T. Alkemade", + title="{Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 7590 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7590", + pages="1--9", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7590.txt", + key="RFC 7590", + abstract={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.}, + keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Secure Sockets Layer, SSL, Transport Layer Security, TLS, instant messaging, presence, encryption, authentication", + doi="10.17487/RFC7590", + } + +@misc{rfc7591, + author="J. {Richer (Ed.)} and M. Jones and J. Bradley and M. Machulak and P. Hunt", + title="{OAuth 2.0 Dynamic Client Registration Protocol}", + howpublished="RFC 7591 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7591", + pages="1--39", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7591.txt", + key="RFC 7591", + abstract={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.}, + keywords="OpenID Connect Dynamic Client Registration, OpenID Connect, oidc, openid, user managed access, uma, Dynamic Registration, Dynamic Client Registration", + doi="10.17487/RFC7591", + } + +@misc{rfc7592, + author="J. {Richer (Ed.)} and M. Jones and J. Bradley and M. Machulak", + title="{OAuth 2.0 Dynamic Client Registration Management Protocol}", + howpublished="RFC 7592 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7592", + pages="1--18", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7592.txt", + key="RFC 7592", + abstract={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.}, + doi="10.17487/RFC7592", + } + +@misc{rfc7593, + author="K. Wierenga and S. Winter and T. Wolniewicz", + title="{The eduroam Architecture for Network Roaming}", + howpublished="RFC 7593 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7593", + pages="1--37", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7593.txt", + key="RFC 7593", + abstract={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.}, + keywords="Federated Authentication, AAA, RADIUS, IEEE 802.1X, roaming, EAP, eduroam", + doi="10.17487/RFC7593", + } + +@misc{rfc7594, + author="P. Eardley and A. Morton and M. Bagnulo and T. Burbridge and P. Aitken and A. Akhter", + title="{A Framework for Large-Scale Measurement of Broadband Performance (LMAP)}", + howpublished="RFC 7594 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7594", + pages="1--55", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7594.txt", + key="RFC 7594", + abstract={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).}, + keywords="Controller, Collector, Measurement Agent, Metric, Measurement Method, Measurement Results, Registry", + doi="10.17487/RFC7594", + } + +@misc{rfc7595, + author="D. {Thaler (Ed.)} and T. Hansen and T. Hardie", + title="{Guidelines and Registration Procedures for URI Schemes}", + howpublished="RFC 7595 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7595", + pages="1--19", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7595.txt", + key="RFC 7595", + abstract={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.}, + keywords="URI scheme, IRI, Internationalized Resource Identifier, Uniform Resource Identifier, URI registration", + doi="10.17487/RFC7595", + } + +@misc{rfc7596, + author="Y. Cui and Q. Sun and M. Boucadair and T. Tsou and Y. Lee and I. Farrer", + title="{Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture}", + howpublished="RFC 7596 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7596", + pages="1--22", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7596.txt", + key="RFC 7596", + abstract={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.}, + keywords="DS-Lite, address sharing, address exhaustion, aplusp, A+P, IPv4 service continuity, IPv4 over IPv6 connectivity", + doi="10.17487/RFC7596", + } + +@misc{rfc7597, + author="O. {Troan (Ed.)} and W. Dec and X. Li and C. Bao and S. Matsushima and T. Murakami and T. {Taylor (Ed.)}", + title="{Mapping of Address and Port with Encapsulation (MAP-E)}", + howpublished="RFC 7597 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7597", + pages="1--35", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7597.txt", + key="RFC 7597", + abstract={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.}, + doi="10.17487/RFC7597", + } + +@misc{rfc7598, + author="T. Mrugalski and O. Troan and I. Farrer and S. Perreault and W. Dec and C. Bao and L. Yeh and X. Deng", + title="{DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients}", + howpublished="RFC 7598 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7598", + pages="1--18", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7598.txt", + key="RFC 7598", + abstract={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.}, + keywords="MAP, DHCPv6", + doi="10.17487/RFC7598", + } + +@misc{rfc7599, + author="X. Li and C. Bao and W. {Dec (Ed.)} and O. Troan and S. Matsushima and T. Murakami", + title="{Mapping of Address and Port using Translation (MAP-T)}", + howpublished="RFC 7599 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7599", + pages="1--27", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7599.txt", + key="RFC 7599", + abstract={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.}, + doi="10.17487/RFC7599", + } + +@misc{rfc7600, + author="R. Despres and S. {Jiang (Ed.)} and R. Penno and Y. Lee and G. Chen and M. Chen", + title="{IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)}", + howpublished="RFC 7600 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7600", + pages="1--45", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7600.txt", + key="RFC 7600", + abstract={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.}, + keywords="Coexistence, Transition, Interworking, Tunneling, Stateless, 4rd, IPv4, IPv6, Mapping, Global Addressing", + doi="10.17487/RFC7600", + } + +@misc{rfc7601, + author="M. Kucherawy", + title="{Message Header Field for Indicating Message Authentication Status}", + howpublished="RFC 7601 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7601", + pages="1--53", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7601.txt", + key="RFC 7601", + abstract={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.}, + keywords="DKIM, DomainKeys, SenderID, SPF, ADSP, ATPS, VBR, Authentication, Reputation", + doi="10.17487/RFC7601", + } + +@misc{rfc7602, + author="U. Chunduri and W. Lu and A. Tian and N. Shen", + title="{IS-IS Extended Sequence Number TLV}", + howpublished="RFC 7602 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7602", + pages="1--12", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7602.txt", + key="RFC 7602", + abstract={This document defines the Extended Sequence Number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks.}, + doi="10.17487/RFC7602", + } + +@misc{rfc7603, + author="B. Schoening and M. Chandramouli and B. Nordman", + title="{Energy Management (EMAN) Applicability Statement}", + howpublished="RFC 7603 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7603", + pages="1--28", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7603.txt", + key="RFC 7603", + abstract={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.}, + doi="10.17487/RFC7603", + } + +@misc{rfc7604, + author="M. Westerlund and T. Zeng", + title="{Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)}", + howpublished="RFC 7604 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7604", + pages="1--46", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7604.txt", + key="RFC 7604", + abstract={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.}, + keywords="RTP, Real-time Transport Protocol, Real-time, Firewall, UDP", + doi="10.17487/RFC7604", + } + +@misc{rfc7605, + author="J. Touch", + title="{Recommendations on Using Assigned Transport Port Numbers}", + howpublished="RFC 7605 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7605", + pages="1--24", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7605.txt", + key="RFC 7605", + abstract={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.}, + keywords="tcp, udp, sctp, dccp, service, iana", + doi="10.17487/RFC7605", + } + +@misc{rfc7606, + author="E. {Chen (Ed.)} and J. {Scudder (Ed.)} and P. Mohapatra and K. Patel", + title="{Revised Error Handling for BGP UPDATE Messages}", + howpublished="RFC 7606 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7606", + pages="1--19", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7606.txt", + key="RFC 7606", + abstract={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. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.}, + keywords="BGP", + doi="10.17487/RFC7606", + } + +@misc{rfc7607, + author="W. Kumari and R. Bush and H. Schiller and K. Patel", + title="{Codification of AS 0 Processing}", + howpublished="RFC 7607 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7607", + pages="1--5", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7607.txt", + key="RFC 7607", + abstract={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.}, + keywords="BGP, AS 0, AS\_PATH, AS-PATH", + doi="10.17487/RFC7607", + } + +@misc{rfc7608, + author="M. Boucadair and A. Petrescu and F. Baker", + title="{IPv6 Prefix Length Recommendation for Forwarding}", + howpublished="RFC 7608 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7608", + pages="1--6", + year=2015, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7608.txt", + key="RFC 7608", + abstract={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.}, + keywords="IPv6 Routing, CIDR, Classless Inter-Domain Routing, IPv6 Addressing Architecture, IPv6 Forwarding Information Base, IPv6 Routing Information Base, FIB, RIB, IPv6 Deployment", + doi="10.17487/RFC7608", + } + +@misc{rfc7609, + author="M. Fox and C. Kassimis and J. Stevens", + title="{IBM's Shared Memory Communications over RDMA (SMC-R) Protocol}", + howpublished="RFC 7609 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7609", + pages="1--143", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7609.txt", + key="RFC 7609", + abstract={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.}, + doi="10.17487/RFC7609", + } + +@misc{rfc7610, + author="F. Gont and W. Liu and G. Van de Velde", + title="{DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers}", + howpublished="RFC 7610 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7610", + pages="1--12", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7610.txt", + key="RFC 7610", + abstract={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.}, + doi="10.17487/RFC7610", + } + +@misc{rfc7611, + author="J. Uttaro and P. Mohapatra and D. Smith and R. Raszuk and J. Scudder", + title="{BGP ACCEPT\_OWN Community Attribute}", + howpublished="RFC 7611 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7611", + pages="1--8", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7611.txt", + key="RFC 7611", + abstract={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.}, + keywords="BGP, VPN, L3VPN, Extranet, Well-known, Reserved", + doi="10.17487/RFC7611", + } + +@misc{rfc7612, + author="P. Fleming and I. McDonald", + title="{Lightweight Directory Access Protocol (LDAP): Schema for Printer Services}", + howpublished="RFC 7612 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7612", + pages="1--54", + year=2015, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7612.txt", + key="RFC 7612", + abstract={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). 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. This document obsoletes RFC 3712.}, + doi="10.17487/RFC7612", + } + +@misc{rfc7613, + author="P. Saint-Andre and A. Melnikov", + title="{Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords}", + howpublished="RFC 7613 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7613", + pages="1--27", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8265", +url="https://www.rfc-editor.org/rfc/rfc7613.txt", + key="RFC 7613", + abstract={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.}, + keywords="Username, Password, Unicode, Internationalization, i18n, Authentication, SASLprep, strings, stringprep", + doi="10.17487/RFC7613", + } + +@misc{rfc7614, + author="R. Sparks", + title="{Explicit Subscriptions for the REFER Method}", + howpublished="RFC 7614 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7614", + pages="1--14", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7614.txt", + key="RFC 7614", + abstract={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.}, + keywords="SIP, SIP Events, nosub, explicitsub, Refer-Events-At", + doi="10.17487/RFC7614", + } + +@misc{rfc7615, + author="J. Reschke", + title="{HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields}", + howpublished="RFC 7615 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7615", + pages="1--6", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7615.txt", + key="RFC 7615", + abstract={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.}, + keywords="HTTP, authentication", + doi="10.17487/RFC7615", + } + +@misc{rfc7616, + author="R. {Shekh-Yusef (Ed.)} and D. Ahrens and S. Bremer", + title="{HTTP Digest Access Authentication}", + howpublished="RFC 7616 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7616", + pages="1--32", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7616.txt", + key="RFC 7616", + abstract={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.}, + keywords="HTTP, authentication scheme", + doi="10.17487/RFC7616", + } + +@misc{rfc7617, + author="J. Reschke", + title="{The 'Basic' HTTP Authentication Scheme}", + howpublished="RFC 7617 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7617", + pages="1--15", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7617.txt", + key="RFC 7617", + abstract={This document defines the ``Basic'' Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.}, + keywords="HTTP, authentication scheme, basic authentication scheme", + doi="10.17487/RFC7617", + } + +@misc{rfc7618, + author="Y. Cui and Q. Sun and I. Farrer and Y. Lee and Q. Sun and M. Boucadair", + title="{Dynamic Allocation of Shared IPv4 Addresses}", + howpublished="RFC 7618 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7618", + pages="1--15", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7618.txt", + key="RFC 7618", + abstract={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. 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.}, + doi="10.17487/RFC7618", + } + +@misc{rfc7619, + author="V. Smyslov and P. Wouters", + title="{The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 7619 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7619", + pages="1--12", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7619.txt", + key="RFC 7619", + abstract={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.}, + keywords="unauthenticated, opportunistic security, pervasive monitoring, Peer Authorization Database, PAD, opportunistic encryption", + doi="10.17487/RFC7619", + } + +@misc{rfc7620, + author="M. {Boucadair (Ed.)} and B. Chatras and T. Reddy and B. Williams and B. Sarikaya", + title="{Scenarios with Host Identification Complications}", + howpublished="RFC 7620 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7620", + pages="1--26", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7620.txt", + key="RFC 7620", + abstract={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. This document does not include any solution-specific discussions.}, + keywords="IP address sharing, IPv4 service continuity, host identifier, de-multiplexing connections, policy enforcement, service delivery", + doi="10.17487/RFC7620", + } + +@misc{rfc7621, + author="A.B. Roach", + title="{A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework}", + howpublished="RFC 7621 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7621", + pages="1--4", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7621.txt", + key="RFC 7621", + abstract={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. This document updates RFC 6665.}, + keywords="session initiation protocol", + doi="10.17487/RFC7621", + } + +@misc{rfc7622, + author="P. Saint-Andre", + title="{Extensible Messaging and Presence Protocol (XMPP): Address Format}", + howpublished="RFC 7622 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7622", + pages="1--27", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7622.txt", + key="RFC 7622", + abstract={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.}, + keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Messaging, Instant Messaging, Presence, Internationalization, i18n, PRECIS", + doi="10.17487/RFC7622", + } + +@misc{rfc7623, + author="A. {Sajassi (Ed.)} and S. Salam and N. Bitar and A. Isaac and W. Henderickx", + title="{Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)}", + howpublished="RFC 7623 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7623", + pages="1--23", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7623.txt", + key="RFC 7623", + abstract={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.}, + doi="10.17487/RFC7623", + } + +@misc{rfc7624, + author="R. Barnes and B. Schneier and C. Jennings and T. Hardie and B. Trammell and C. Huitema and D. Borkmann", + title="{Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement}", + howpublished="RFC 7624 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7624", + pages="1--24", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7624.txt", + key="RFC 7624", + abstract={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.}, + keywords="eavesdropping", + doi="10.17487/RFC7624", + } + +@misc{rfc7625, + author="J. T. Hao and P. Maheshwari and R. Huang and L. Andersson and M. Chen", + title="{Architecture of an IP/MPLS Network with Hardened Pipes}", + howpublished="RFC 7625 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7625", + pages="1--15", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7625.txt", + key="RFC 7625", + abstract={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''. 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. 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. 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.}, + doi="10.17487/RFC7625", + } + +@misc{rfc7626, + author="S. Bortzmeyer", + title="{DNS Privacy Considerations}", + howpublished="RFC 7626 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7626", + pages="1--17", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7626.txt", + key="RFC 7626", + abstract={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.}, + keywords="Confidentiality, Pervasive Surveillance, Domain Name System", + doi="10.17487/RFC7626", + } + +@misc{rfc7627, + author="K. {Bhargavan (Ed.)} and A. Delignat-Lavaud and A. Pironti and A. Langley and M. Ray", + title="{Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension}", + howpublished="RFC 7627 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7627", + pages="1--15", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7627.txt", + key="RFC 7627", + abstract={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.}, + doi="10.17487/RFC7627", + } + +@misc{rfc7628, + author="W. Mills and T. Showalter and H. Tschofenig", + title="{A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth}", + howpublished="RFC 7628 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7628", + pages="1--21", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7628.txt", + key="RFC 7628", + abstract={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. 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. 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.} , + doi="10.17487/RFC7628", + } + +@misc{rfc7629, + author="S. {Gundavelli (Ed.)} and K. Leung and G. Tsirtsis and A. Petrescu", + title="{Flow-Binding Support for Mobile IP}", + howpublished="RFC 7629 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7629", + pages="1--19", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7629.txt", + key="RFC 7629", + abstract={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.}, + keywords="Multipath, Flow Binding, Hybrid Access, Flow Mobility, MIPv4-NEMO", + doi="10.17487/RFC7629", + } + +@misc{rfc7630, + author="J. {Merkle (Ed.)} and M. Lochter", + title="{HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3}", + howpublished="RFC 7630 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7630", + pages="1--14", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7860", +url="https://www.rfc-editor.org/rfc/rfc7630.txt", + key="RFC 7630", + abstract={This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.}, + keywords="Network, Management, SNMP, USM, HMAC, SHA-2", + doi="10.17487/RFC7630", + } + +@misc{rfc7631, + author="C. Dearlove and T. Clausen", + title="{TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format}", + howpublished="RFC 7631 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7631", + pages="1--15", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 7722", +url="https://www.rfc-editor.org/rfc/rfc7631.txt", + key="RFC 7631", + abstract={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. 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.}, + keywords="MANET, packet, message, address, TLV", + doi="10.17487/RFC7631", + } + +@misc{rfc7632, + author="D. Waltermire and D. Harrington", + title="{Endpoint Security Posture Assessment: Enterprise Use Cases}", + howpublished="RFC 7632 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7632", + pages="1--23", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7632.txt", + key="RFC 7632", + abstract={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.}, + keywords="security automation, continuous monitoring, endpoint, posture assessment, use case, asset management, configuration management, vulnerability management, content management", + doi="10.17487/RFC7632", + } + +@misc{rfc7633, + author="P. Hallam-Baker", + title="{X.509v3 Transport Layer Security (TLS) Feature Extension}", + howpublished="RFC 7633 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7633", + pages="1--11", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7633.txt", + key="RFC 7633", + abstract={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.}, + keywords="PKIX, Transport Layer Security, Cryptography Certificate", + doi="10.17487/RFC7633", + } + +@misc{rfc7634, + author="Y. Nir", + title="{ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec}", + howpublished="RFC 7634 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7634", + pages="1--13", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7634.txt", + key="RFC 7634", + abstract={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.}, + keywords="IKE, IPsec, AEAD, ChaCha, ChaCha20, Salsa", + doi="10.17487/RFC7634", + } + +@misc{rfc7635, + author="T. Reddy and P. Patil and R. Ravindranath and J. Uberti", + title="{Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization}", + howpublished="RFC 7635 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7635", + pages="1--24", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7635.txt", + key="RFC 7635", + abstract={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.}, + keywords="OAuth 2.0, STUN, TURN, WebRTC, Authentication and Authorization", + doi="10.17487/RFC7635", + } + +@misc{rfc7636, + author="N. {Sakimura (Ed.)} and J. Bradley and N. Agarwal", + title="{Proof Key for Code Exchange by OAuth Public Clients}", + howpublished="RFC 7636 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7636", + pages="1--20", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7636.txt", + key="RFC 7636", + abstract={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'').}, + keywords="smart phones, apps, XARA, authorization, custom scheme, intent, man-in-the-middle, eavesdropping, user agent swap, spop, pop, openid, connect , pkce, pixie", + doi="10.17487/RFC7636", + } + +@misc{rfc7637, + author="P. {Garg (Ed.)} and Y. {Wang (Ed.)}", + title="{NVGRE: Network Virtualization Using Generic Routing Encapsulation}", + howpublished="RFC 7637 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7637", + pages="1--17", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7637.txt", + key="RFC 7637", + abstract={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.}, + doi="10.17487/RFC7637", + } + +@misc{rfc7638, + author="M. Jones and N. Sakimura", + title="{JSON Web Key (JWK) Thumbprint}", + howpublished="RFC 7638 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7638", + pages="1--13", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7638.txt", + key="RFC 7638", + abstract={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.}, + keywords="JavaScript Object Notation, JSON, JSON Web Key, JWK, ThumbprintOB, Fingerprint, Digest", + doi="10.17487/RFC7638", + } + +@misc{rfc7639, + author="A. Hutton and J. Uberti and M. Thomson", + title="{The ALPN HTTP Header Field}", + howpublished="RFC 7639 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7639", + pages="1--7", + year=2015, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7639.txt", + key="RFC 7639", + abstract={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.}, + keywords="HTTP CONNECT, Firewall, HTTP proxy", + doi="10.17487/RFC7639", + } + +@misc{rfc7640, + author="B. Constantine and R. Krishnan", + title="{Traffic Management Benchmarking}", + howpublished="RFC 7640 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7640", + pages="1--51", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7640.txt", + key="RFC 7640", + abstract={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.}, + doi="10.17487/RFC7640", + } + +@misc{rfc7641, + author="K. Hartke", + title="{Observing Resources in the Constrained Application Protocol (CoAP)}", + howpublished="RFC 7641 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7641", + pages="1--30", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8323", +url="https://www.rfc-editor.org/rfc/rfc7641.txt", + key="RFC 7641", + abstract={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.}, + keywords="Smart Objects, Internet of Things, IoT, REST", + doi="10.17487/RFC7641", + } + +@misc{rfc7642, + author="K. {LI (Ed.)} and P. Hunt and B. Khasnabish and A. Nadalin and Z. Zeltsan", + title="{System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements}", + howpublished="RFC 7642 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7642", + pages="1--19", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7642.txt", + key="RFC 7642", + abstract={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.}, + keywords="SIM user scenarios, SCIM use cases", + doi="10.17487/RFC7642", + } + +@misc{rfc7643, + author="P. {Hunt (Ed.)} and K. Grizzle and E. Wahlstroem and C. Mortimore", + title="{System for Cross-domain Identity Management: Core Schema}", + howpublished="RFC 7643 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7643", + pages="1--104", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7643.txt", + key="RFC 7643", + abstract={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. 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.}, + keywords="Identity, Provisioning, User, Group", + doi="10.17487/RFC7643", + } + +@misc{rfc7644, + author="P. {Hunt (Ed.)} and K. Grizzle and M. Ansari and E. Wahlstroem and C. Mortimore", + title="{System for Cross-domain Identity Management: Protocol}", + howpublished="RFC 7644 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7644", + pages="1--89", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7644.txt", + key="RFC 7644", + abstract={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.}, + keywords="SCIM", + doi="10.17487/RFC7644", + } + +@misc{rfc7645, + author="U. Chunduri and A. Tian and W. Lu", + title="{The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis}", + howpublished="RFC 7645 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7645", + pages="1--12", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7645.txt", + key="RFC 7645", + abstract={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.}, + doi="10.17487/RFC7645", + } + +@misc{rfc7646, + author="P. Ebersman and W. Kumari and C. Griffiths and J. Livingood and R. Weber", + title="{Definition and Use of DNSSEC Negative Trust Anchors}", + howpublished="RFC 7646 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7646", + pages="1--16", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7646.txt", + key="RFC 7646", + abstract={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.}, + keywords="NTA, ISP, Internet Service Provider, DNS, DNSSEC, Negative Trust Anchors", + doi="10.17487/RFC7646", + } + +@misc{rfc7647, + author="R. Sparks and A.B. Roach", + title="{Clarifications for the Use of REFER with RFC 6665}", + howpublished="RFC 7647 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7647", + pages="1--6", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7647.txt", + key="RFC 7647", + abstract={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.}, + doi="10.17487/RFC7647", + } + +@misc{rfc7648, + author="S. Perreault and M. Boucadair and R. Penno and D. Wing and S. Cheshire", + title="{Port Control Protocol (PCP) Proxy Function}", + howpublished="RFC 7648 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7648", + pages="1--14", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7648.txt", + key="RFC 7648", + abstract={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.}, + keywords="NAT, firewall, CGN, AFTR, NAT64, port forwarding, pinholing, port mapping, external IP address, discover port number, running a server behind NAT, NAT control, NAT cascading, DS-Lite, incoming connection, control outbound connection, referral, address referral, ALG offload, PCP client, PCP server", + doi="10.17487/RFC7648", + } + +@misc{rfc7649, + author="P. Saint-Andre and D. York", + title="{The Jabber Scribe Role at IETF Meetings}", + howpublished="RFC 7649 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7649", + pages="1--12", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7649.txt", + key="RFC 7649", + abstract={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.}, + keywords="Jabber Scribe, IETF Meetings", + doi="10.17487/RFC7649", + } + +@misc{rfc7650, + author="J. Jimenez and J. Lopez-Vega and J. Maenpaa and G. Camarillo", + title="{A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)}", + howpublished="RFC 7650 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7650", + pages="1--19", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7650.txt", + key="RFC 7650", + abstract={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.}, + keywords="CoAP, RELOAD", + doi="10.17487/RFC7650", + } + +@misc{rfc7651, + author="A. Dodd-Noble and S. Gundavelli and J. Korhonen and F. Baboescu and B. Weis", + title="{3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 7651 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7651", + pages="1--10", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7651.txt", + key="RFC 7651", + abstract={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.}, + keywords="P-CSCF, P-CSCF Option for IKEv2, Proxy-Call Session Control Function, IMS Option for IKEv2", + doi="10.17487/RFC7651", + } + +@misc{rfc7652, + author="M. Cullen and S. Hartman and D. Zhang and T. Reddy", + title="{Port Control Protocol (PCP) Authentication Mechanism}", + howpublished="RFC 7652 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7652", + pages="1--34", + year=2015, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7652.txt", + key="RFC 7652", + abstract={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. This document updates RFC 6887.}, + doi="10.17487/RFC7652", + } + +@misc{rfc7653, + author="D. Raghuvanshi and K. Kinnear and D. Kukrety", + title="{DHCPv6 Active Leasequery}", + howpublished="RFC 7653 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7653", + pages="1--30", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7653.txt", + key="RFC 7653", + abstract={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.}, + keywords="DHCP, IPv6, ACTIVELEASEQUERY, DHCPv6", + doi="10.17487/RFC7653", + } + +@misc{rfc7654, + author="S. Banks and F. Calabria and G. Czirjak and R. Machat", + title="{Benchmarking Methodology for In-Service Software Upgrade (ISSU)}", + howpublished="RFC 7654 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7654", + pages="1--16", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7654.txt", + key="RFC 7654", + abstract={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.}, + doi="10.17487/RFC7654", + } + +@misc{rfc7655, + author="M. {Ramalho (Ed.)} and P. Jones and N. Harada and M. Perumal and L. Miao", + title="{RTP Payload Format for G.711.0}", + howpublished="RFC 7655 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7655", + pages="1--32", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7655.txt", + key="RFC 7655", + abstract={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.}, + keywords="G.711.0, G.711, G.711ZIP, Lossless G.711 Compression, G.711 Data Compression Algorithm", + doi="10.17487/RFC7655", + } + +@misc{rfc7656, + author="J. Lennox and K. Gross and S. Nandakumar and G. Salgueiro and B. {Burman (Ed.)}", + title="{A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources}", + howpublished="RFC 7656 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7656", + pages="1--46", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7656.txt", + key="RFC 7656", + abstract={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.}, + keywords="Taxonomy, Terminology, RTP, Grouping", + doi="10.17487/RFC7656", + } + +@misc{rfc7657, + author="D. {Black (Ed.)} and P. Jones", + title="{Differentiated Services (Diffserv) and Real-Time Communication}", + howpublished="RFC 7657 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7657", + pages="1--26", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7657.txt", + key="RFC 7657", + abstract={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 implicat ions of these Diffserv aspects for real-time network communication, including WebRTC.}, + keywords="Diffserv, DSCP, RAI, RTP", + doi="10.17487/RFC7657", + } + +@misc{rfc7658, + author="S. Perreault and T. Tsou and S. Sivakumar and T. Taylor", + title="{Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs)}", + howpublished="RFC 7658 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7658", + pages="1--62", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7658.txt", + key="RFC 7658", + abstract={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. 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.}, + keywords="NATV2-MIB, management information base", + doi="10.17487/RFC7658", + } + +@misc{rfc7659, + author="S. Perreault and T. Tsou and S. Sivakumar and T. Taylor", + title="{Definitions of Managed Objects for Network Address Translators (NATs)}", + howpublished="RFC 7659 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7659", + pages="1--84", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7659.txt", + key="RFC 7659", + abstract={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).}, + keywords="MIB, management information base, NATV2-MIB, NAT-MIB, basic nat, pooled nat, carrier-grade nat, CGN", + doi="10.17487/RFC7659", + } + +@misc{rfc7660, + author="L. Bertz and S. Manning and B. Hirschman", + title="{Diameter Congestion and Filter Attributes}", + howpublished="RFC 7660 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7660", + pages="1--9", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7660.txt", + key="RFC 7660", + abstract={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. 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. 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. The optional attribute s defined in this document are forward and backwards compatible with RFC 5777.}, + doi="10.17487/RFC7660", + } + +@misc{rfc7661, + author="G. Fairhurst and A. Sathiaseelan and R. Secchi", + title="{Updating TCP to Support Rate-Limited Traffic}", + howpublished="RFC 7661 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7661", + pages="1--21", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7661.txt", + key="RFC 7661", + abstract={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. 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.}, + keywords="CWV, TCP", + doi="10.17487/RFC7661", + } + +@misc{rfc7662, + author="J. {Richer (Ed.)}", + title="{OAuth 2.0 Token Introspection}", + howpublished="RFC 7662 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7662", + pages="1--17", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7662.txt", + key="RFC 7662", + abstract={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.}, + keywords="token validation, oauth token validation, active token, inactive token, token metadata, token status, token status check", + doi="10.17487/RFC7662", + } + +@misc{rfc7663, + author="B. {Trammell (Ed.)} and M. {Kuehlewind (Ed.)}", + title="{Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)}", + howpublished="RFC 7663 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7663", + pages="1--13", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7663.txt", + key="RFC 7663", + abstract={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.}, + keywords="transport layer, TCP, UDP, encapsulation", + doi="10.17487/RFC7663", + } + +@misc{rfc7664, + author="D. {Harkins (Ed.)}", + title="{Dragonfly Key Exchange}", + howpublished="RFC 7664 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7664", + pages="1--18", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7664.txt", + key="RFC 7664", + abstract={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).}, + keywords="elliptic curve, PAKE, AKE, dictionary attack, password authentication", + doi="10.17487/RFC7664", + } + +@misc{rfc7665, + author="J. {Halpern (Ed.)} and C. {Pignataro (Ed.)}", + title="{Service Function Chaining (SFC) Architecture}", + howpublished="RFC 7665 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7665", + pages="1--32", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7665.txt", + key="RFC 7665", + abstract={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.}, + doi="10.17487/RFC7665", + } + +@misc{rfc7666, + author="H. Asai and M. MacFaden and J. Schoenwaelder and K. Shima and T. Tsou", + title="{Management Information Base for Virtual Machines Controlled by a Hypervisor}", + howpublished="RFC 7666 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7666", + pages="1--52", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7666.txt", + key="RFC 7666", + abstract={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).}, + keywords="MIB, Hypervisor, Virtual Machine, VM-MIB, IANA-STORAGE-MEDIA-TYPE-MIB", + doi="10.17487/RFC7666", + } + +@misc{rfc7667, + author="M. Westerlund and S. Wenger", + title="{RTP Topologies}", + howpublished="RFC 7667 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7667", + pages="1--48", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7667.txt", + key="RFC 7667", + abstract={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.}, + keywords="Real-time, Multi-party, Mixer, Relay, SFM, Selective Forwarding Middlebox, Translator, Multicast, ASM, SSM", + doi="10.17487/RFC7667", + } + +@misc{rfc7668, + author="J. Nieminen and T. Savolainen and M. Isomaki and B. Patil and Z. Shelby and C. Gomez", + title="{IPv6 over BLUETOOTH(R) Low Energy}", + howpublished="RFC 7668 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7668", + pages="1--21", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7668.txt", + key="RFC 7668", + abstract={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.}, + keywords="Bluetooth Low Energy, 6lowpan, IPv6, Low power", + doi="10.17487/RFC7668", + } + +@misc{rfc7669, + author="J. Levine", + title="{Assigning Digital Object Identifiers to RFCs}", + howpublished="RFC 7669 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7669", + pages="1--7", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7669.txt", + key="RFC 7669", + abstract={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.}, + doi="10.17487/RFC7669", + } + +@misc{rfc7670, + author="T. Kivinen and P. Wouters and H. Tschofenig", + title="{Generic Raw Public-Key Support for IKEv2}", + howpublished="RFC 7670 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7670", + pages="1--10", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7670.txt", + key="RFC 7670", + abstract={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.}, + keywords="Internet Key Exchange Version 2", + doi="10.17487/RFC7670", + } + +@misc{rfc7671, + author="V. Dukhovni and W. Hardaker", + title="{The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance}", + howpublished="RFC 7671 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7671", + pages="1--33", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7671.txt", + key="RFC 7671", + abstract={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.}, + keywords="DANE, TLSA", + doi="10.17487/RFC7671", + } + +@misc{rfc7672, + author="V. Dukhovni and W. Hardaker", + title="{SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)}", + howpublished="RFC 7672 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7672", + pages="1--34", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7672.txt", + key="RFC 7672", + abstract={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).}, + keywords="DANE, TLSA, SMTP", + doi="10.17487/RFC7672", + } + +@misc{rfc7673, + author="T. Finch and M. Miller and P. Saint-Andre", + title="{Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records}", + howpublished="RFC 7673 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7673", + pages="1--16", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7673.txt", + key="RFC 7673", + abstract={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.}, + doi="10.17487/RFC7673", + } + +@misc{rfc7674, + author="J. {Haas (Ed.)}", + title="{Clarification of the Flowspec Redirect Extended Community}", + howpublished="RFC 7674 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7674", + pages="1--7", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7674.txt", + key="RFC 7674", + abstract={This document updates RFC 5575 (``Dissemination of Flow Specification Rules'') to clarify the formatting of the BGP Flowspec Redirect Extended Community.}, + keywords="bgp, flowspec", + doi="10.17487/RFC7674", + } + +@misc{rfc7675, + author="M. Perumal and D. Wing and R. Ravindranath and T. Reddy and M. Thomson", + title="{Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness}", + howpublished="RFC 7675 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7675", + pages="1--10", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7675.txt", + key="RFC 7675", + abstract={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. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.}, + keywords="WebRTC", + doi="10.17487/RFC7675", + } + +@misc{rfc7676, + author="C. Pignataro and R. Bonica and S. Krishnan", + title="{IPv6 Support for Generic Routing Encapsulation (GRE)}", + howpublished="RFC 7676 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7676", + pages="1--11", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7676.txt", + key="RFC 7676", + abstract={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. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.}, + keywords="GRE, IPv6", + doi="10.17487/RFC7676", + } + +@misc{rfc7677, + author="T. Hansen", + title="{SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms}", + howpublished="RFC 7677 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7677", + pages="1--8", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7677.txt", + key="RFC 7677", + abstract={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.}, + doi="10.17487/RFC7677", + } + +@misc{rfc7678, + author="C. Zhou and T. Taylor and Q. Sun and M. Boucadair", + title="{Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions}", + howpublished="RFC 7678 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7678", + pages="1--23", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7678.txt", + key="RFC 7678", + abstract={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.}, + keywords="DS-Lite, Lightweight 4over6, MAP-E, IPv4 service continuity, IPv6 deployment, IPv4 address sharing, Diameter, Multicast, IPv4 over IPv6", + doi="10.17487/RFC7678", + } + +@misc{rfc7679, + author="G. Almes and S. Kalidindi and M. Zekauskas and A. {Morton (Ed.)}", + title="{A One-Way Delay Metric for IP Performance Metrics (IPPM)}", + howpublished="RFC 7679 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="7679", + pages="1--27", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7679.txt", + key="RFC 7679", + abstract={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.}, + keywords="Performance, Measurement, Quality of Service (QoS)", + doi="10.17487/RFC7679", + } + +@misc{rfc7680, + author="G. Almes and S. Kalidindi and M. Zekauskas and A. {Morton (Ed.)}", + title="{A One-Way Loss Metric for IP Performance Metrics (IPPM)}", + howpublished="RFC 7680 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="7680", + pages="1--22", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7680.txt", + key="RFC 7680", + abstract={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.}, + keywords="Performance, Measurement, Quality of Service (QoS)", + doi="10.17487/RFC7680", + } + +@misc{rfc7681, + author="J. Davin", + title="{Email Exchange of Secondary School Transcripts}", + howpublished="RFC 7681 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7681", + pages="1--40", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7681.txt", + key="RFC 7681", + abstract={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.}, + keywords="Internet Applications, email, school transcript, MIME, OpenPGP", + doi="10.17487/RFC7681", + } + +@misc{rfc7682, + author="D. McPherson and S. Amante and E. Osterweil and L. Blunk and D. Mitchell", + title="{Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration}", + howpublished="RFC 7682 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7682", + pages="1--18", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7682.txt", + key="RFC 7682", + abstract={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.}, + keywords="Resource Certification, Internet Routing Registry, IRR, Routing Policy Specification Language, RPSL", + doi="10.17487/RFC7682", + } + +@misc{rfc7683, + author="J. {Korhonen (Ed.)} and S. {Donovan (Ed.)} and B. Campbell and L. Morand", + title="{Diameter Overload Indication Conveyance}", + howpublished="RFC 7683 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7683", + pages="1--42", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7683.txt", + key="RFC 7683", + abstract={This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC).}, + keywords="DOIC", + doi="10.17487/RFC7683", + } + +@misc{rfc7684, + author="P. Psenak and H. Gredler and R. Shakir and W. Henderickx and J. Tantsura and A. Lindem", + title="{OSPFv2 Prefix/Link Attribute Advertisement}", + howpublished="RFC 7684 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7684", + pages="1--15", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7684.txt", + key="RFC 7684", + abstract={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.}, + keywords="OSPF-LSA, open shortest path first, link state advertisement, Opaque LSA", + doi="10.17487/RFC7684", + } + +@misc{rfc7685, + author="A. Langley", + title="{A Transport Layer Security (TLS) ClientHello Padding Extension}", + howpublished="RFC 7685 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7685", + pages="1--4", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7685.txt", + key="RFC 7685", + abstract={This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.}, + doi="10.17487/RFC7685", + } + +@misc{rfc7686, + author="J. Appelbaum and A. Muffett", + title="{The ``.onion'' Special-Use Domain Name}", + howpublished="RFC 7686 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7686", + pages="1--7", + year=2015, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7686.txt", + key="RFC 7686", + abstract={This document registers the ``.onion'' Special-Use Domain Name.}, + doi="10.17487/RFC7686", + } + +@misc{rfc7687, + author="S. Farrell and R. Wenning and B. Bos and M. Blanchet and H. Tschofenig", + title="{Report from the Strengthening the Internet (STRINT) Workshop}", + howpublished="RFC 7687 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7687", + pages="1--32", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7687.txt", + key="RFC 7687", + abstract={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. 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.}, + keywords="IAB, W3C, STREWS, security, pervasive monitoring, London", + doi="10.17487/RFC7687", + } + +@misc{rfc7688, + author="Y. {Lee (Ed.)} and G. {Bernstein (Ed.)}", + title="{GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks}", + howpublished="RFC 7688 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7688", + pages="1--12", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7688.txt", + key="RFC 7688", + abstract={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. 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.}, + doi="10.17487/RFC7688", + } + +@misc{rfc7689, + author="G. {Bernstein (Ed.)} and S. Xu and Y. {Lee (Ed.)} and G. Martinelli and H. Harai", + title="{Signaling Extensions for Wavelength Switched Optical Networks}", + howpublished="RFC 7689 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7689", + pages="1--16", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7689.txt", + key="RFC 7689", + abstract={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.}, + doi="10.17487/RFC7689", + } + +@misc{rfc7690, + author="M. Byerly and M. Hite and J. Jaeggli", + title="{Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))}", + howpublished="RFC 7690 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7690", + pages="1--9", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7690.txt", + key="RFC 7690", + abstract={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.}, + keywords="IPv6, ICMP6, ICMPv6 type 2 PTB", + doi="10.17487/RFC7690", + } + +@misc{rfc7691, + author="S. {Bradner (Ed.)}", + title="{Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members}", + howpublished="RFC 7691 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7691", + pages="1--4", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7691.txt", + key="RFC 7691", + abstract={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.}, + doi="10.17487/RFC7691", + } + +@misc{rfc7692, + author="T. Yoshino", + title="{Compression Extensions for WebSocket}", + howpublished="RFC 7692 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7692", + pages="1--28", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7692.txt", + key="RFC 7692", + abstract={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.}, + keywords="DEFLATE, LZ77", + doi="10.17487/RFC7692", + } + +@misc{rfc7693, + author="M-J. {Saarinen (Ed.)} and J-P. Aumasson", + title="{The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)}", + howpublished="RFC 7693 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7693", + pages="1--30", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7693.txt", + key="RFC 7693", + abstract={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).}, + keywords="BLAKE2, Cryptographic Hash", + doi="10.17487/RFC7693", + } + +@misc{rfc7694, + author="J. Reschke", + title="{Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding}", + howpublished="RFC 7694 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7694", + pages="1--7", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7694.txt", + key="RFC 7694", + abstract={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. 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.}, + keywords="HTTP, content-encoding", + doi="10.17487/RFC7694", + } + +@misc{rfc7695, + author="P. Pfister and B. Paterson and J. Arkko", + title="{Distributed Prefix Assignment Algorithm}", + howpublished="RFC 7695 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7695", + pages="1--20", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7695.txt", + key="RFC 7695", + abstract={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.}, + keywords="distributed, prefix, address, assignment, homenet", + doi="10.17487/RFC7695", + } + +@misc{rfc7696, + author="R. Housley", + title="{Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms}", + howpublished="RFC 7696 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7696", + pages="1--19", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7696.txt", + key="RFC 7696", + abstract={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.}, + doi="10.17487/RFC7696", + } + +@misc{rfc7697, + author="P. Pan and S. Aldrin and M. Venkatesan and K. Sampath and T. Nadeau and S. Boutros", + title="{MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)}", + howpublished="RFC 7697 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7697", + pages="1--36", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7697.txt", + key="RFC 7697", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure the Operations, Administration, and Maintenance (OAM) identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP).}, + keywords="MPLS-OAM-ID-STD-MIB", + doi="10.17487/RFC7697", + } + +@misc{rfc7698, + author="O. Gonzalez de {Dios (Ed.)} and R. {Casellas (Ed.)} and F. Zhang and X. Fu and D. Ceccarelli and I. Hussain", + title="{Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks}", + howpublished="RFC 7698 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7698", + pages="1--42", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7698.txt", + key="RFC 7698", + abstract={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). 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.}, + keywords="DWDM, Flexi-Grid, GMPLS", + doi="10.17487/RFC7698", + } + +@misc{rfc7699, + author="A. Farrel and D. King and Y. Li and F. Zhang", + title="{Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers}", + howpublished="RFC 7699 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7699", + pages="1--14", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7699.txt", + key="RFC 7699", + abstract={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. This document updates RFCs 3471 and 6205 by introducing a new label format.}, + keywords="GMPLS, RSVP-TE", + doi="10.17487/RFC7699", + } + +@misc{rfc7700, + author="P. Saint-Andre", + title="{Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames}", + howpublished="RFC 7700 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7700", + pages="1--11", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8266", +url="https://www.rfc-editor.org/rfc/rfc7700.txt", + key="RFC 7700", + abstract={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.}, + keywords="nickname, SIP, SIMPLE, XMPP, MSRP, XCON, chatrooms", + doi="10.17487/RFC7700", + } + +@misc{rfc7701, + author="A. Niemi and M. Garcia-Martin and G. Sandbakken", + title="{Multi-party Chat Using the Message Session Relay Protocol (MSRP)}", + howpublished="RFC 7701 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7701", + pages="1--42", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7701.txt", + key="RFC 7701", + abstract={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.}, + keywords="messaging, message sessions, multi-party, chat, MSRP, SIMPLE", + doi="10.17487/RFC7701", + } + +@misc{rfc7702, + author="P. Saint-Andre and S. Ibarra and S. Loreto", + title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat}", + howpublished="RFC 7702 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7702", + pages="1--43", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7702.txt", + key="RFC 7702", + abstract={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.}, + keywords="Text Chat, Groupchat, Instant Messaging, Session Initiation Protocol, SIP, Message Sessions Relay Protocol, MSRP, Extensible Messaging and Presence Protocol, XMPP", + doi="10.17487/RFC7702", + } + +@misc{rfc7703, + author="E. Cordeiro and R. Carnier and A. Moreiras", + title="{Experience with Testing of Mapping of Address and Port Using Translation (MAP-T)}", + howpublished="RFC 7703 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7703", + pages="1--56", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7703.txt", + key="RFC 7703", + abstract={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. The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines.}, + keywords="template", + doi="10.17487/RFC7703", + } + +@misc{rfc7704, + author="D. Crocker and N. Clark", + title="{An IETF with Much Diversity and Professional Conduct}", + howpublished="RFC 7704 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7704", + pages="1--18", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7704.txt", + key="RFC 7704", + abstract={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.}, + doi="10.17487/RFC7704", + } + +@misc{rfc7705, + author="W. George and S. Amante", + title="{Autonomous System Migration Mechanisms and Their Effects on the BGP AS\_PATH Attribute}", + howpublished="RFC 7705 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7705", + pages="1--16", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7705.txt", + key="RFC 7705", + abstract={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.}, + keywords="as-migration, AS-migration, AS\_migration, AS migration, IDR, BGP", + doi="10.17487/RFC7705", + } + +@misc{rfc7706, + author="W. Kumari and P. Hoffman", + title="{Decreasing Access Time to Root Servers by Running One on Loopback}", + howpublished="RFC 7706 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7706", + pages="1--12", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7706.txt", + key="RFC 7706", + abstract={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.}, + doi="10.17487/RFC7706", + } + +@misc{rfc7707, + author="F. Gont and T. Chown", + title="{Network Reconnaissance in IPv6 Networks}", + howpublished="RFC 7707 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7707", + pages="1--38", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7707.txt", + key="RFC 7707", + abstract={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.}, + doi="10.17487/RFC7707", + } + +@misc{rfc7708, + author="T. Nadeau and L. Martini and S. Bryant", + title="{Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator}", + howpublished="RFC 7708 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7708", + pages="1--9", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7708.txt", + key="RFC 7708", + abstract={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).}, + keywords="VCCV, GAL", + doi="10.17487/RFC7708", + } + +@misc{rfc7709, + author="A. {Malis (Ed.)} and B. Wilson and G. Clapp and V. Shukla", + title="{Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)}", + howpublished="RFC 7709 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7709", + pages="1--9", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7709.txt", + key="RFC 7709", + abstract={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. The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).}, + keywords="generalized multiprotocol label switching, OTN, optical transport networks, WSON, TDM, WDM, churn, on-demand, wavelength, rapid setup", + doi="10.17487/RFC7709", + } + +@misc{rfc7710, + author="W. Kumari and O. Gudmundsson and P. Ebersman and S. Sheng", + title="{Captive-Portal Identification Using DHCP or Router Advertisements (RAs)}", + howpublished="RFC 7710 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7710", + pages="1--8", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7710.txt", + key="RFC 7710", + abstract={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. 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.}, + doi="10.17487/RFC7710", + } + +@misc{rfc7711, + author="M. Miller and P. Saint-Andre", + title="{PKIX over Secure HTTP (POSH)}", + howpublished="RFC 7711 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7711", + pages="1--18", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7711.txt", + key="RFC 7711", + abstract={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.}, + keywords="Extensible Messaging and Presence Protocol, Jabber, federation", + doi="10.17487/RFC7711", + } + +@misc{rfc7712, + author="P. Saint-Andre and M. Miller and P. Hancke", + title="{Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)}", + howpublished="RFC 7712 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7712", + pages="1--24", + year=2015, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7712.txt", + key="RFC 7712", + abstract={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.}, + keywords="XMPP, Extensible Messaging and Presence Protocol, Jabber, federation, delegation, security", + doi="10.17487/RFC7712", + } + +@misc{rfc7713, + author="M. Mathis and B. Briscoe", + title="{Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements}", + howpublished="RFC 7713 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7713", + pages="1--30", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7713.txt", + key="RFC 7713", + abstract={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.}, + keywords="Quality of Service, QoS, Congestion Control, Signaling, Protocol, Encoding, Audit, Policing", + doi="10.17487/RFC7713", + } + +@misc{rfc7714, + author="D. McGrew and K. Igoe", + title="{AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)}", + howpublished="RFC 7714 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7714", + pages="1--48", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7714.txt", + key="RFC 7714", + abstract={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).}, + doi="10.17487/RFC7714", + } + +@misc{rfc7715, + author="IJ. {Wijnands (Ed.)} and K. Raza and A. Atlas and J. Tantsura and Q. Zhao", + title="{Multipoint LDP (mLDP) Node Protection}", + howpublished="RFC 7715 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7715", + pages="1--19", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7715.txt", + key="RFC 7715", + abstract={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.}, + doi="10.17487/RFC7715", + } + +@misc{rfc7716, + author="J. Zhang and L. Giuliano and E. {Rosen (Ed.)} and K. Subramanian and D. Pacella", + title="{Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures}", + howpublished="RFC 7716 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7716", + pages="1--22", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7716.txt", + key="RFC 7716", + abstract={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.}, + keywords="Multicast", + doi="10.17487/RFC7716", + } + +@misc{rfc7717, + author="K. {Pentikousis (Ed.)} and E. Zhang and Y. Cui", + title="{IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)}", + howpublished="RFC 7717 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7717", + pages="1--15", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7717.txt", + key="RFC 7717", + abstract={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.}, + doi="10.17487/RFC7717", + } + +@misc{rfc7718, + author="A. Morton", + title="{Registries for the One-Way Active Measurement Protocol (OWAMP)}", + howpublished="RFC 7718 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7718", + pages="1--7", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7718.txt", + key="RFC 7718", + abstract={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.}, + doi="10.17487/RFC7718", + } + +@misc{rfc7719, + author="P. Hoffman and A. Sullivan and K. Fujiwara", + title="{DNS Terminology}", + howpublished="RFC 7719 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7719", + pages="1--27", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7719.txt", + key="RFC 7719", + abstract={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.}, + doi="10.17487/RFC7719", + } + +@misc{rfc7720, + author="M. Blanchet and L-J. Liman", + title="{DNS Root Name Service Protocol and Deployment Requirements}", + howpublished="RFC 7720 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7720", + pages="1--6", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7720.txt", + key="RFC 7720", + abstract={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.}, + doi="10.17487/RFC7720", + } + +@misc{rfc7721, + author="A. Cooper and F. Gont and D. Thaler", + title="{Security and Privacy Considerations for IPv6 Address Generation Mechanisms}", + howpublished="RFC 7721 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7721", + pages="1--18", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7721.txt", + key="RFC 7721", + abstract={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.}, + doi="10.17487/RFC7721", + } + +@misc{rfc7722, + author="C. Dearlove and T. Clausen", + title="{Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)}", + howpublished="RFC 7722 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7722", + pages="1--23", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7722.txt", + key="RFC 7722", + abstract={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. This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.}, + doi="10.17487/RFC7722", + } + +@misc{rfc7723, + author="S. Kiesel and R. Penno", + title="{Port Control Protocol (PCP) Anycast Addresses}", + howpublished="RFC 7723 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7723", + pages="1--9", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7723.txt", + key="RFC 7723", + abstract={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.}, + keywords="Port Control Protocol, anycast address, anycast server discovery, Port Control Protocol server discovery, port mapping, NAT control, firewall control", + doi="10.17487/RFC7723", + } + +@misc{rfc7724, + author="K. Kinnear and M. Stapp and B. Volz and N. Russell", + title="{Active DHCPv4 Lease Query}", + howpublished="RFC 7724 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7724", + pages="1--28", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7724.txt", + key="RFC 7724", + abstract={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''.}, + doi="10.17487/RFC7724", + } + +@misc{rfc7725, + author="T. Bray", + title="{An HTTP Status Code to Report Legal Obstacles}", + howpublished="RFC 7725 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7725", + pages="1--5", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7725.txt", + key="RFC 7725", + abstract={This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.}, + keywords="Hypertext Transfer Protocol", + doi="10.17487/RFC7725", + } + +@misc{rfc7726, + author="V. Govindan and K. Rajaraman and G. Mirsky and N. Akiya and S. Aldrin", + title="{Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)}", + howpublished="RFC 7726 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7726", + pages="1--7", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7726.txt", + key="RFC 7726", + abstract={This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.}, + keywords="RFC5884, MPLS, LSP, BFD, RFC 5884", + doi="10.17487/RFC7726", + } + +@misc{rfc7727, + author="M. Zhang and H. Wen and J. Hu", + title="{Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)}", + howpublished="RFC 7727 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7727", + pages="1--25", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7727.txt", + key="RFC 7727", + abstract={The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability. 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.}, + doi="10.17487/RFC7727", + } + +@misc{rfc7728, + author="B. Burman and A. Akram and R. Even and M. Westerlund", + title="{RTP Stream Pause and Resume}", + howpublished="RFC 7728 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7728", + pages="1--55", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7728.txt", + key="RFC 7728", + abstract={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.}, + keywords="CCM, RTCP, Feedback, Bandwidth, PAUSED, REFUSED, TMMBR, TMMBN, Mixer, MCU", + doi="10.17487/RFC7728", + } + +@misc{rfc7729, + author="B. Khasnabish and E. Haleplidis and J. Hadi {Salim (Ed.)}", + title="{Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management}", + howpublished="RFC 7729 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7729", + pages="1--20", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7729.txt", + key="RFC 7729", + abstract={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.}, + keywords="ForCES, LFB, Subsidiary Management, Virtualization", + doi="10.17487/RFC7729", + } + +@misc{rfc7730, + author="G. Huston and S. Weiler and G. Michaelson and S. Kent", + title="{Resource Public Key Infrastructure (RPKI) Trust Anchor Locator}", + howpublished="RFC 7730 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7730", + pages="1--8", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7730.txt", + key="RFC 7730", + abstract={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.}, + keywords="RPKI, BGP Security", + doi="10.17487/RFC7730", + } + +@misc{rfc7731, + author="J. Hui and R. Kelsey", + title="{Multicast Protocol for Low-Power and Lossy Networks (MPL)}", + howpublished="RFC 7731 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7731", + pages="1--29", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7731.txt", + key="RFC 7731", + abstract={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. 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.}, + keywords="6lowpan, 802.15.4, IPv6, LLN, ROLL, mesh network, trickle, wsn, wireless sensor network", + doi="10.17487/RFC7731", + } + +@misc{rfc7732, + author="P. van der Stok and R. Cragie", + title="{Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)}", + howpublished="RFC 7732 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7732", + pages="1--15", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7732.txt", + key="RFC 7732", + abstract={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.}, + keywords="routing, MPL, multicast policy, IP networks", + doi="10.17487/RFC7732", + } + +@misc{rfc7733, + author="A. Brandt and E. Baccelli and R. Cragie and P. van der Stok", + title="{Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control}", + howpublished="RFC 7733 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7733", + pages="1--38", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7733.txt", + key="RFC 7733", + abstract={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.}, + keywords="sensor network, ad hoc network, routing, RPL, applicability, building control, home automation, IP networks", + doi="10.17487/RFC7733", + } + +@misc{rfc7734, + author="D. {Allan (Ed.)} and J. Tantsura and D. Fedyk and A. Sajassi", + title="{Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)}", + howpublished="RFC 7734 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7734", + pages="1--11", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7734.txt", + key="RFC 7734", + abstract={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.}, + keywords="SPBM, Provider Backbone Bridging Provider Edges, PBB-EVPN", + doi="10.17487/RFC7734", + } + +@misc{rfc7735, + author="R. Sparks and T. Kivinen", + title="{Tracking Reviews of Documents}", + howpublished="RFC 7735 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7735", + pages="1--16", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7735.txt", + key="RFC 7735", + abstract={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.}, + keywords="review tool requirements", + doi="10.17487/RFC7735", + } + +@misc{rfc7736, + author="K. Ma", + title="{Content Delivery Network Interconnection (CDNI) Media Type Registration}", + howpublished="RFC 7736 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7736", + pages="1--7", + year=2015, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7736.txt", + key="RFC 7736", + abstract={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.}, + keywords="CDNI, CDN Interconnect, CDN, content delivery, content delivery network", + doi="10.17487/RFC7736", + } + +@misc{rfc7737, + author="N. Akiya and G. Swallow and C. Pignataro and L. Andersson and M. Chen", + title="{Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification}", + howpublished="RFC 7737 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7737", + pages="1--17", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7737.txt", + key="RFC 7737", + abstract={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.}, + keywords="MPLS, LSP Ping, Reply Mode", + doi="10.17487/RFC7737", + } + +@misc{rfc7738, + author="M. Blanchet and A. Schiltknecht and P. Shames", + title="{A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)}", + howpublished="RFC 7738 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7738", + pages="1--8", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7738.txt", + key="RFC 7738", + abstract={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).}, + doi="10.17487/RFC7738", + } + +@misc{rfc7739, + author="F. Gont", + title="{Security Implications of Predictable Fragment Identification Values}", + howpublished="RFC 7739 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7739", + pages="1--20", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7739.txt", + key="RFC 7739", + abstract={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 implica tions are mitigated.}, + keywords="attack, vulnerability, Denial of Service, protocol identifiers", + doi="10.17487/RFC7739", + } + +@misc{rfc7740, + author="Z. Zhang and Y. Rekhter and A. Dolganow", + title="{Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication}", + howpublished="RFC 7740 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7740", + pages="1--8", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7740.txt", + key="RFC 7740", + abstract={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.}, + keywords="MVPN, Ingress Replication, Bidirectional C-flow, p-tunnel", + doi="10.17487/RFC7740", + } + +@misc{rfc7741, + author="P. Westin and H. Lundin and M. Glover and J. Uberti and F. Galligan", + title="{RTP Payload Format for VP8 Video}", + howpublished="RFC 7741 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7741", + pages="1--27", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7741.txt", + key="RFC 7741", + abstract={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.}, + keywords="RTP, V8, WebM", + doi="10.17487/RFC7741", + } + +@misc{rfc7742, + author="A.B. Roach", + title="{WebRTC Video Processing and Codec Requirements}", + howpublished="RFC 7742 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7742", + pages="1--10", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7742.txt", + key="RFC 7742", + abstract={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.}, + keywords="MTI, mandatory-to-implement", + doi="10.17487/RFC7742", + } + +@misc{rfc7743, + author="J. {Luo (Ed.)} and L. {Jin (Ed.)} and T. {Nadeau (Ed.)} and G. {Swallow (Ed.)}", + title="{Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping}", + howpublished="RFC 7743 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7743", + pages="1--18", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7743.txt", + key="RFC 7743", + abstract={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.}, + doi="10.17487/RFC7743", + } + +@misc{rfc7744, + author="L. {Seitz (Ed.)} and S. {Gerdes (Ed.)} and G. Selander and M. Mani and S. Kumar", + title="{Use Cases for Authentication and Authorization in Constrained Environments}", + howpublished="RFC 7744 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7744", + pages="1--30", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7744.txt", + key="RFC 7744", + abstract={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. 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. 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.}, + keywords="Internet of Things, IoT, Smart Object, Security", + doi="10.17487/RFC7744", + } + +@misc{rfc7745, + author="T. Manderson", + title="{XML Schemas for Reverse DNS Management}", + howpublished="RFC 7745 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7745", + pages="1--10", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7745.txt", + key="RFC 7745", + abstract={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.}, + doi="10.17487/RFC7745", + } + +@misc{rfc7746, + author="R. Bonica and I. Minei and M. Conn and D. Pacella and L. Tomotaki", + title="{Label Switched Path (LSP) Self-Ping}", + howpublished="RFC 7746 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7746", + pages="1--12", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7746.txt", + key="RFC 7746", + abstract={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. 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. 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. LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.}, + doi="10.17487/RFC7746", + } + +@misc{rfc7747, + author="R. Papneja and B. Parise and S. Hares and D. Lee and I. Varlashkin", + title="{Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence}", + howpublished="RFC 7747 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7747", + pages="1--35", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7747.txt", + key="RFC 7747", + abstract={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.}, + keywords="BMWG", + doi="10.17487/RFC7747", + } + +@misc{rfc7748, + author="A. Langley and M. Hamburg and S. Turner", + title="{Elliptic Curves for Security}", + howpublished="RFC 7748 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7748", + pages="1--22", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7748.txt", + key="RFC 7748", + abstract={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.}, + keywords="elliptic curve, cryptography, ecc", + doi="10.17487/RFC7748", + } + +@misc{rfc7749, + author="J. Reschke", + title="{The ``xml2rfc'' Version 2 Vocabulary}", + howpublished="RFC 7749 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7749", + pages="1--76", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 7991", +url="https://www.rfc-editor.org/rfc/rfc7749.txt", + key="RFC 7749", + abstract={This document defines the ``xml2rfc'' version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014. This document obsoletes RFC 2629.}, + keywords="XML, IETF, RFC, Internet-Draft, Vocabulary", + doi="10.17487/RFC7749", + } + +@misc{rfc7750, + author="J. Hedin and G. Mirsky and S. Baillargeon", + title="{Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)}", + howpublished="RFC 7750 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7750", + pages="1--11", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7750.txt", + key="RFC 7750", + abstract={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.}, + keywords="IPPM, TWAMP, Type-P Descriptor", + doi="10.17487/RFC7750", + } + +@misc{rfc7751, + author="S. Sorce and T. Yu", + title="{Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)}", + howpublished="RFC 7751 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7751", + pages="1--10", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7751.txt", + key="RFC 7751", + abstract={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.}, + keywords="Kerberos", + doi="10.17487/RFC7751", + } + +@misc{rfc7752, + author="H. {Gredler (Ed.)} and J. Medved and S. Previdi and A. Farrel and S. Ray", + title="{North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP}", + howpublished="RFC 7752 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7752", + pages="1--48", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7752.txt", + key="RFC 7752", + abstract={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. 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. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).}, + keywords="BGP, North-Bound, API, Link-State, Topology, Controller, Multi-Area, Multi-AS", + doi="10.17487/RFC7752", + } + +@misc{rfc7753, + author="Q. Sun and M. Boucadair and S. Sivakumar and C. Zhou and T. Tsou and S. Perreault", + title="{Port Control Protocol (PCP) Extension for Port-Set Allocation}", + howpublished="RFC 7753 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7753", + pages="1--19", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7753.txt", + key="RFC 7753", + abstract={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.}, + keywords="IPv4 service continuity, IPv4 address shortage, A+P, AplusP, address plus port, MAP, Port range, Port Range Router, MAP-E, port set mapping, port bulk", + doi="10.17487/RFC7753", + } + +@misc{rfc7754, + author="R. Barnes and A. Cooper and O. Kolkman and D. Thaler and E. Nordmark", + title="{Technical Considerations for Internet Service Blocking and Filtering}", + howpublished="RFC 7754 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7754", + pages="1--33", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7754.txt", + key="RFC 7754", + abstract={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 un intended consequences to third parties, and we discuss the limits of efficacy of various approaches.}, + keywords="Firewall, Filter, Deep Packet Inspection, Domain Name Seizure, Web Portal, Web Proxy", + doi="10.17487/RFC7754", + } + +@misc{rfc7755, + author="T. Anderson", + title="{SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments}", + howpublished="RFC 7755 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7755", + pages="1--24", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7755.txt", + key="RFC 7755", + abstract={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. 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.}, + keywords="Data Centre, Data Center, Dual Stack, Single Stack, IDC, IPv4, IPv4 conservation, IPv4 exhaustion, IPv6-only, IPv6 only, IPv6 transition, IPv6 transition technology, XLAT", + doi="10.17487/RFC7755", + } + +@misc{rfc7756, + author="T. Anderson and S. Steffann", + title="{Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode}", + howpublished="RFC 7756 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7756", + pages="1--17", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7756.txt", + key="RFC 7756", + abstract={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. The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.}, + keywords="Data Centre, Data Center, Dual Stack, Single Stack, IDC, IPv4, IPv4 conservation, IPv4 exhaustion, IPv6-only, IPv6 only, IPv6 transition, IPv6 transition technology, XLAT", + doi="10.17487/RFC7756", + } + +@misc{rfc7757, + author="T. Anderson and A. Leiva Popper", + title="{Explicit Address Mappings for Stateless IP/ICMP Translation}", + howpublished="RFC 7757 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7757", + pages="1--19", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7757.txt", + key="RFC 7757", + abstract={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.}, + keywords="Dual Stack, Single Stack, IPv4, IPv4 conservation, IPv4 exhaustion, IPv6-only, IPv6 only, IPv6 transition, IPv6 transition technology, XLAT", + doi="10.17487/RFC7757", + } + +@misc{rfc7758, + author="T. Mizrahi and Y. Moses", + title="{Time Capability in NETCONF}", + howpublished="RFC 7758 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7758", + pages="1--32", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7758.txt", + key="RFC 7758", + abstract={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.}, + keywords="NETCONF, network management, time, clock synchronization", + doi="10.17487/RFC7758", + } + +@misc{rfc7759, + author="E. Bellagamba and G. Mirsky and L. Andersson and P. Skoldstrom and D. Ward and J. Drake", + title="{Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping}", + howpublished="RFC 7759 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7759", + pages="1--29", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7759.txt", + key="RFC 7759", + abstract={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.}, + keywords="LSP-PING, MPLS, MPLS-TP, OAM", + doi="10.17487/RFC7759", + } + +@misc{rfc7760, + author="R. Housley", + title="{Statement of Work for Extensions to the IETF Datatracker for Author Statistics}", + howpublished="RFC 7760 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7760", + pages="1--8", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7760.txt", + key="RFC 7760", + abstract={This is the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors.}, + doi="10.17487/RFC7760", + } + +@misc{rfc7761, + author="B. Fenner and M. Handley and H. Holbrook and I. Kouvelas and R. Parekh and Z. Zhang and L. Zheng", + title="{Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)}", + howpublished="RFC 7761 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="7761", + pages="1--137", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7761.txt", + key="RFC 7761", + abstract={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. 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.}, + doi="10.17487/RFC7761", + } + +@misc{rfc7762, + author="M. West", + title="{Initial Assignment for the Content Security Policy Directives Registry}", + howpublished="RFC 7762 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7762", + pages="1--5", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7762.txt", + key="RFC 7762", + abstract={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.}, + doi="10.17487/RFC7762", + } + +@misc{rfc7763, + author="S. Leonard", + title="{The text/markdown Media Type}", + howpublished="RFC 7763 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7763", + pages="1--15", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7763.txt", + key="RFC 7763", + abstract={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.}, + doi="10.17487/RFC7763", + } + +@misc{rfc7764, + author="S. Leonard", + title="{Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations}", + howpublished="RFC 7764 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7764", + pages="1--28", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7764.txt", + key="RFC 7764", + abstract={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.}, + keywords="text/markdown", + doi="10.17487/RFC7764", + } + +@misc{rfc7765, + author="P. Hurtig and A. Brunstrom and A. Petlund and M. Welzl", + title="{TCP and Stream Control Transmission Protocol (SCTP) RTO Restart}", + howpublished="RFC 7765 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7765", + pages="1--15", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7765.txt", + key="RFC 7765", + abstract={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.}, + keywords="tcp, retransmission timer, rtor", + doi="10.17487/RFC7765", + } + +@misc{rfc7766, + author="J. Dickinson and S. Dickinson and R. Bellis and A. Mankin and D. Wessels", + title="{DNS Transport over TCP - Implementation Requirements}", + howpublished="RFC 7766 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7766", + pages="1--19", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7766.txt", + key="RFC 7766", + abstract={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.}, + keywords="DNS, TCP/IP, transport", + doi="10.17487/RFC7766", + } + +@misc{rfc7767, + author="S. Vinapamula and S. Sivakumar and M. Boucadair and T. Reddy", + title="{Application-Initiated Check-Pointing via the Port Control Protocol (PCP)}", + howpublished="RFC 7767 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7767", + pages="1--12", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7767.txt", + key="RFC 7767", + abstract={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. 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.}, + keywords="serviceability, SDN, resilience, robustness, network programmability, network API, application control, service-aware networking, automation", + doi="10.17487/RFC7767", + } + +@misc{rfc7768, + author="T. Tsou and W. Li and T. Taylor and J. Huang", + title="{Port Management to Reduce Logging in Large-Scale NATs}", + howpublished="RFC 7768 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7768", + pages="1--11", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7768.txt", + key="RFC 7768", + abstract={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.}, + doi="10.17487/RFC7768", + } + +@misc{rfc7769, + author="S. Sivabalan and S. Boutros and H. Shah and S. Aldrin and M. Venkatesan", + title="{Media Access Control (MAC) Address Withdrawal over Static Pseudowire}", + howpublished="RFC 7769 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7769", + pages="1--10", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7769.txt", + key="RFC 7769", + abstract={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.}, + keywords="PW, ACH, associated channel", + doi="10.17487/RFC7769", + } + +@misc{rfc7770, + author="A. {Lindem (Ed.)} and N. Shen and JP. Vasseur and R. Aggarwal and S. Shaffer", + title="{Extensions to OSPF for Advertising Optional Router Capabilities}", + howpublished="RFC 7770 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7770", + pages="1--15", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7770.txt", + key="RFC 7770", + abstract={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.}, + keywords="ospfv2, ospfv3, open shortest path first, ri, router information, lsa, link state advertisement", + doi="10.17487/RFC7770", + } + +@misc{rfc7771, + author="A. {Malis (Ed.)} and L. Andersson and H. van Helvoort and J. Shin and L. Wang and A. D'Alessandro", + title="{Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires}", + howpublished="RFC 7771 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7771", + pages="1--9", + year=2016, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7771.txt", + key="RFC 7771", + abstract={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.}, + keywords="end-to-end protection, linear protection", + doi="10.17487/RFC7771", + } + +@misc{rfc7772, + author="A. Yourtchenko and L. Colitti", + title="{Reducing Energy Consumption of Router Advertisements}", + howpublished="RFC 7772 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7772", + pages="1--6", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7772.txt", + key="RFC 7772", + abstract={Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.}, + doi="10.17487/RFC7772", + } + +@misc{rfc7773, + author="S. Santesson", + title="{Authentication Context Certificate Extension}", + howpublished="RFC 7773 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7773", + pages="1--16", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7773.txt", + key="RFC 7773", + abstract={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. 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.}, + doi="10.17487/RFC7773", + } + +@misc{rfc7774, + author="Y. Doi and M. Gillmore", + title="{Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6}", + howpublished="RFC 7774 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7774", + pages="1--10", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7774.txt", + key="RFC 7774", + abstract={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.}, + keywords="MPL, DHCPv6", + doi="10.17487/RFC7774", + } + +@misc{rfc7775, + author="L. Ginsberg and S. Litkowski and S. Previdi", + title="{IS-IS Route Preference for Extended IP and IPv6 Reachability}", + howpublished="RFC 7775 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7775", + pages="1--11", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7775.txt", + key="RFC 7775", + abstract={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.}, + doi="10.17487/RFC7775", + } + +@misc{rfc7776, + author="P. Resnick and A. Farrel", + title="{IETF Anti-Harassment Procedures}", + howpublished="RFC 7776 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7776", + pages="1--18", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7776.txt", + key="RFC 7776", + abstract={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. 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.}, + keywords="Ombudsman, Ombudsperson, Ombudsteam", + doi="10.17487/RFC7776", + } + +@misc{rfc7777, + author="S. Hegde and R. Shakir and A. Smirnov and Z. Li and B. Decraene", + title="{Advertising Node Administrative Tags in OSPF}", + howpublished="RFC 7777 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7777", + pages="1--15", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7777.txt", + key="RFC 7777", + abstract={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. 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.}, + keywords="open shortest path first", + doi="10.17487/RFC7777", + } + +@misc{rfc7778, + author="D. Kutscher and F. Mir and R. Winter and S. Krishnan and Y. Zhang and CJ. Bernardos", + title="{Mobile Communication Congestion Exposure Scenario}", + howpublished="RFC 7778 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7778", + pages="1--25", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7778.txt", + key="RFC 7778", + abstract={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.}, + keywords="congestion exposure, mobile communications", + doi="10.17487/RFC7778", + } + +@misc{rfc7779, + author="H. Rogge and E. Baccelli", + title="{Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)}", + howpublished="RFC 7779 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7779", + pages="1--21", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7779.txt", + key="RFC 7779", + abstract={This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).}, + keywords="MANET, metric, ad hoc network, routing, IP networks, OLSR, ETT, ETX, Funkfeuer, DAT", + doi="10.17487/RFC7779", + } + +@misc{rfc7780, + author="D. {Eastlake 3rd} and M. Zhang and R. Perlman and A. Banerjee and A. Ghanwani and S. Gupta", + title="{Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates}", + howpublished="RFC 7780 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7780", + pages="1--57", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8249", +url="https://www.rfc-editor.org/rfc/rfc7780.txt", + key="RFC 7780", + abstract={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.}, + keywords="TRILL, RBridge, IS-IS, reachability, overload, MTU, DEI, multicast, RPF, color, E-L1FS, purge", + doi="10.17487/RFC7780", + } + +@misc{rfc7781, + author="H. Zhai and T. Senevirathne and R. Perlman and M. Zhang and Y. Li", + title="{Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access}", + howpublished="RFC 7781 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7781", + pages="1--35", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7781.txt", + key="RFC 7781", + abstract={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.}, + keywords="virtual RBridge, aggregation, flip-flopping", + doi="10.17487/RFC7781", + } + +@misc{rfc7782, + author="M. Zhang and R. Perlman and H. Zhai and M. Durrani and S. Gupta", + title="{Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments}", + howpublished="RFC 7782 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7782", + pages="1--22", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7782.txt", + key="RFC 7782", + abstract={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. 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.}, + keywords="LAALP, vSwitch, MC-LAG, DRNI", + doi="10.17487/RFC7782", + } + +@misc{rfc7783, + author="T. Senevirathne and J. Pathangi and J. Hudson", + title="{Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)}", + howpublished="RFC 7783 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7783", + pages="1--16", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7783.txt", + key="RFC 7783", + abstract={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 mul ti-destination distribution tree. This document updates RFC 6325.}, + keywords="Affinity, RPF", + doi="10.17487/RFC7783", + } + +@misc{rfc7784, + author="D. Kumar and S. Salam and T. Senevirathne", + title="{Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB}", + howpublished="RFC 7784 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7784", + pages="1--50", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7784.txt", + key="RFC 7784", + abstract={This document specifies the MIB for the OAM (Operations, Administration, and Maintenance) objects for IETF TRILL (Transparent Interconnection of Lots of Links).}, + keywords="CFM, MEP, MIP, Fault Management", + doi="10.17487/RFC7784", + } + +@misc{rfc7785, + author="S. Vinapamula and M. Boucadair", + title="{Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite}", + howpublished="RFC 7785 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7785", + pages="1--9", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7785.txt", + key="RFC 7785", + abstract={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.}, + keywords="IPv4 service continuity, IPv4 address exhaustion, Service Availability, High Availability, Address sharing, IPv6, Reliability, IPv4 over IPv6, State migration, Stability, Disruption, Privacy", + doi="10.17487/RFC7785", + } + +@misc{rfc7786, + author="M. {Kuehlewind (Ed.)} and R. Scheffenegger", + title="{TCP Modifications for Congestion Exposure (ConEx)}", + howpublished="RFC 7786 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7786", + pages="1--20", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7786.txt", + key="RFC 7786", + abstract={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).}, + doi="10.17487/RFC7786", + } + +@misc{rfc7787, + author="M. Stenberg and S. Barth", + title="{Distributed Node Consensus Protocol}", + howpublished="RFC 7787 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7787", + pages="1--41", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7787.txt", + key="RFC 7787", + abstract={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.}, + keywords="Homenet", + doi="10.17487/RFC7787", + } + +@misc{rfc7788, + author="M. Stenberg and S. Barth and P. Pfister", + title="{Home Networking Control Protocol}", + howpublished="RFC 7788 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7788", + pages="1--40", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8375", +url="https://www.rfc-editor.org/rfc/rfc7788.txt", + key="RFC 7788", + abstract={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.}, + keywords="IPv6, Homenet, DNCP", + doi="10.17487/RFC7788", + } + +@misc{rfc7789, + author="C. Cardona and P. Francois and P. Lucente", + title="{Impact of BGP Filtering on Inter-Domain Routing Policies}", + howpublished="RFC 7789 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7789", + pages="1--16", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7789.txt", + key="RFC 7789", + abstract={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.}, + keywords="More-specific prefix, Less-specific prefix, Autonomous systems, Traffic engineering", + doi="10.17487/RFC7789", + } + +@misc{rfc7790, + author="Y. Yoneya and T. Nemoto", + title="{Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)}", + howpublished="RFC 7790 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7790", + pages="1--10", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7790.txt", + key="RFC 7790", + abstract={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.}, + doi="10.17487/RFC7790", + } + +@misc{rfc7791, + author="D. {Migault (Ed.)} and V. Smyslov", + title="{Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 7791 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7791", + pages="1--14", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7791.txt", + key="RFC 7791", + abstract={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. 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.}, + keywords="MIF, Load balancing, Load sharing, MOBIKE", + doi="10.17487/RFC7791", + } + +@misc{rfc7792, + author="F. Zhang and X. Zhang and A. Farrel and O. Gonzalez de Dios and D. Ceccarelli", + title="{RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks}", + howpublished="RFC 7792 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7792", + pages="1--12", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7792.txt", + key="RFC 7792", + abstract={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.}, + keywords="Flexible-grid, Flexible optical grid, Optical network, Optical trail, Optical LSP, GMPLS, WDM, PCE, spectrum reservation, flexible spectrum", + doi="10.17487/RFC7792", + } + +@misc{rfc7793, + author="M. Andrews", + title="{Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry}", + howpublished="RFC 7793 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7793", + pages="1--6", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7793.txt", + key="RFC 7793", + abstract={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.'' 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.}, + doi="10.17487/RFC7793", + } + +@misc{rfc7794, + author="L. {Ginsberg (Ed.)} and B. Decraene and S. Previdi and X. Xu and U. Chunduri", + title="{IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability}", + howpublished="RFC 7794 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7794", + pages="1--9", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7794.txt", + key="RFC 7794", + abstract={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.}, + keywords="ISIS", + doi="10.17487/RFC7794", + } + +@misc{rfc7795, + author="J. Dong and H. Wang", + title="{Pseudowire Redundancy on the Switching Provider Edge (S-PE)}", + howpublished="RFC 7795 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7795", + pages="1--9", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7795.txt", + key="RFC 7795", + abstract={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.}, + doi="10.17487/RFC7795", + } + +@misc{rfc7796, + author="Y. {Jiang (Ed.)} and L. Yong and M. Paul", + title="{Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)}", + howpublished="RFC 7796 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7796", + pages="1--26", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7796.txt", + key="RFC 7796", + abstract={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.}, + keywords="Etree", + doi="10.17487/RFC7796", + } + +@misc{rfc7797, + author="M. Jones", + title="{JSON Web Signature (JWS) Unencoded Payload Option}", + howpublished="RFC 7797 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7797", + pages="1--11", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7797.txt", + key="RFC 7797", + abstract={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. This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.}, + keywords="JavaScript Object Notation, JSON, JSON Object Signing and Encryption, JOSE, JSON Web Signature, JWS, Digital Signature, Message Authentication Code, MAC, Unencoded Payload", + doi="10.17487/RFC7797", + } + +@misc{rfc7798, + author="Y.-K. Wang and Y. Sanchez and T. Schierl and S. Wenger and M. M. Hannuksela", + title="{RTP Payload Format for High Efficiency Video Coding (HEVC)}", + howpublished="RFC 7798 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7798", + pages="1--86", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7798.txt", + key="RFC 7798", + abstract={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.}, + keywords="H.265, : ISO/IEC 23008-2, Single NAL Unit Packet, Aggregation Packet, Fragmentation Unit, Payload Content Information Packet, Use of HEVC with Feedback Messages.", + doi="10.17487/RFC7798", + } + +@misc{rfc7799, + author="A. Morton", + title="{Active and Passive Metrics and Methods (with Hybrid Types In-Between)}", + howpublished="RFC 7799 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7799", + pages="1--14", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7799.txt", + key="RFC 7799", + abstract={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.}, + keywords="IP Performance, Measurements, Testing, Network Characterization", + doi="10.17487/RFC7799", + } + +@misc{rfc7800, + author="M. Jones and J. Bradley and H. Tschofenig", + title="{Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)}", + howpublished="RFC 7800 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7800", + pages="1--15", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7800.txt", + key="RFC 7800", + abstract={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.}, + keywords="JSON Web Token, JWT, Proof-of-Possession, Holder-of-Key", + doi="10.17487/RFC7800", + } + +@misc{rfc7801, + author="V. {Dolmatov (Ed.)}", + title="{GOST R 34.12-2015: Block Cipher ``Kuznyechik''}", + howpublished="RFC 7801 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7801", + pages="1--14", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7801.txt", + key="RFC 7801", + abstract={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).}, + keywords="Kuznyechik, Block Cipher", + doi="10.17487/RFC7801", + } + +@misc{rfc7802, + author="S. Emery and N. Williams", + title="{A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism}", + howpublished="RFC 7802 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7802", + pages="1--8", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7802.txt", + key="RFC 7802", + abstract={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. 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.}, + doi="10.17487/RFC7802", + } + +@misc{rfc7803, + author="B. Leiba", + title="{Changing the Registration Policy for the NETCONF Capability URNs Registry}", + howpublished="RFC 7803 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7803", + pages="1--3", + year=2016, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7803.txt", + key="RFC 7803", + abstract={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.}, + doi="10.17487/RFC7803", + } + +@misc{rfc7804, + author="A. Melnikov", + title="{Salted Challenge Response HTTP Authentication Mechanism}", + howpublished="RFC 7804 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7804", + pages="1--18", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7804.txt", + key="RFC 7804", + abstract={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.}, + keywords="HTTPAUTH, HTTP, SASL, SCRAM, GS2, GSSAPI, GSS-API", + doi="10.17487/RFC7804", + } + +@misc{rfc7805, + author="A. Zimmermann and W. Eddy and L. Eggert", + title="{Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status}", + howpublished="RFC 7805 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7805", + pages="1--8", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7805.txt", + key="RFC 7805", + abstract={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.}, + doi="10.17487/RFC7805", + } + +@misc{rfc7806, + author="F. Baker and R. Pan", + title="{On Queuing, Marking, and Dropping}", + howpublished="RFC 7806 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7806", + pages="1--16", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7806.txt", + key="RFC 7806", + abstract={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.}, + doi="10.17487/RFC7806", + } + +@misc{rfc7807, + author="M. Nottingham and E. Wilde", + title="{Problem Details for HTTP APIs}", + howpublished="RFC 7807 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7807", + pages="1--16", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7807.txt", + key="RFC 7807", + abstract={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.}, + keywords="status, HTTP, error, problem, API, JSON, XML", + doi="10.17487/RFC7807", + } + +@misc{rfc7808, + author="M. Douglass and C. Daboo", + title="{Time Zone Data Distribution Service}", + howpublished="RFC 7808 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7808", + pages="1--56", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7808.txt", + key="RFC 7808", + abstract={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.}, + keywords="time zone, calendaring, scheduling", + doi="10.17487/RFC7808", + } + +@misc{rfc7809, + author="C. Daboo", + title="{Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference}", + howpublished="RFC 7809 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7809", + pages="1--13", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7809.txt", + key="RFC 7809", + abstract={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.}, + keywords="CalDAV, calendaring, iCalendar, time zone", + doi="10.17487/RFC7809", + } + +@misc{rfc7810, + author="S. {Previdi (Ed.)} and S. Giacalone and D. Ward and J. Drake and Q. Wu", + title="{IS-IS Traffic Engineering (TE) Metric Extensions}", + howpublished="RFC 7810 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7810", + pages="1--18", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7810.txt", + key="RFC 7810", + abstract={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. 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. 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.}, + doi="10.17487/RFC7810", + } + +@misc{rfc7811, + author="G. Enyedi and A. Csaszar and A. Atlas and C. Bowers and A. Gopalan", + title="{An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)}", + howpublished="RFC 7811 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7811", + pages="1--118", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7811.txt", + key="RFC 7811", + abstract={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.}, + keywords="MRT, FRR, LFA, recovery, failure, routing", + doi="10.17487/RFC7811", + } + +@misc{rfc7812, + author="A. Atlas and C. Bowers and G. Enyedi", + title="{An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)}", + howpublished="RFC 7812 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7812", + pages="1--44", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7812.txt", + key="RFC 7812", + abstract={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.}, + keywords="MRT, FRR, LFA, recovery, failure, routing", + doi="10.17487/RFC7812", + } + +@misc{rfc7813, + author="J. {Farkas (Ed.)} and N. Bragg and P. Unbehagen and G. Parsons and P. Ashwood-Smith and C. Bowers", + title="{IS-IS Path Control and Reservation}", + howpublished="RFC 7813 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7813", + pages="1--33", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7813.txt", + key="RFC 7813", + abstract={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.}, + keywords="IS-IS, SPB", + doi="10.17487/RFC7813", + } + +@misc{rfc7814, + author="X. Xu and C. Jacquenet and R. Raszuk and T. Boyes and B. Fee", + title="{Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution}", + howpublished="RFC 7814 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7814", + pages="1--15", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7814.txt", + key="RFC 7814", + abstract={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.}, + keywords="Data Center Interconnect, Data Center Network, Virtual Machine (VM) migration", + doi="10.17487/RFC7814", + } + +@misc{rfc7815, + author="T. Kivinen", + title="{Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation}", + howpublished="RFC 7815 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7815", + pages="1--41", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7815.txt", + key="RFC 7815", + abstract={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. This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this docu ment and RFC 7296 conflict, then RFC 7296 is the authoritative description.}, + keywords="IKE, IPsec, IoT, Constrained", + doi="10.17487/RFC7815", + } + +@misc{rfc7816, + author="S. Bortzmeyer", + title="{DNS Query Name Minimisation to Improve Privacy}", + howpublished="RFC 7816 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7816", + pages="1--11", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7816.txt", + key="RFC 7816", + abstract={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.}, + doi="10.17487/RFC7816", + } + +@misc{rfc7817, + author="A. Melnikov", + title="{Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols}", + howpublished="RFC 7817 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7817", + pages="1--13", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7817.txt", + key="RFC 7817", + abstract={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.}, + keywords="SMTP, Submission, IMAP, POP, ManageSieve", + doi="10.17487/RFC7817", + } + +@misc{rfc7818, + author="M. Jethanandani", + title="{URN Namespace for MEF Documents}", + howpublished="RFC 7818 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7818", + pages="1--5", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7818.txt", + key="RFC 7818", + abstract={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.}, + doi="10.17487/RFC7818", + } + +@misc{rfc7819, + author="S. Jiang and S. Krishnan and T. Mrugalski", + title="{Privacy Considerations for DHCP}", + howpublished="RFC 7819 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7819", + pages="1--14", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7819.txt", + key="RFC 7819", + abstract={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.}, + keywords="DHCP Privacy", + doi="10.17487/RFC7819", + } + +@misc{rfc7820, + author="T. Mizrahi", + title="{UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)}", + howpublished="RFC 7820 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7820", + pages="1--15", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7820.txt", + key="RFC 7820", + abstract={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.}, + keywords="Checksum, UDP, IPPM, timestamping", + doi="10.17487/RFC7820", + } + +@misc{rfc7821, + author="T. Mizrahi", + title="{UDP Checksum Complement in the Network Time Protocol (NTP)}", + howpublished="RFC 7821 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7821", + pages="1--14", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7821.txt", + key="RFC 7821", + abstract={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.}, + keywords="NTP, UDP, Checksum, timestamping", + doi="10.17487/RFC7821", + } + +@misc{rfc7822, + author="T. Mizrahi and D. Mayer", + title="{Network Time Protocol Version 4 (NTPv4) Extension Fields}", + howpublished="RFC 7822 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7822", + pages="1--8", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7822.txt", + key="RFC 7822", + abstract={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).}, + keywords="NTP, extension field", + doi="10.17487/RFC7822", + } + +@misc{rfc7823, + author="A. Atlas and J. Drake and S. Giacalone and S. Previdi", + title="{Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions}", + howpublished="RFC 7823 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7823", + pages="1--10", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7823.txt", + key="RFC 7823", + abstract={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.}, + keywords="Traffic Engineering, Path Computation", + doi="10.17487/RFC7823", + } + +@misc{rfc7824, + author="S. Krishnan and T. Mrugalski and S. Jiang", + title="{Privacy Considerations for DHCPv6}", + howpublished="RFC 7824 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7824", + pages="1--18", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7824.txt", + key="RFC 7824", + abstract={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.}, + doi="10.17487/RFC7824", + } + +@misc{rfc7825, + author="J. Goldberg and M. Westerlund and T. Zeng", + title="{A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)}", + howpublished="RFC 7825 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7825", + pages="1--33", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7825.txt", + key="RFC 7825", + abstract={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.}, + keywords="ICE, Media Delivery, RTP, RTCP, D-ICE, AVP, AVPF, SAVP, SAVPF, setup.ice-d-m, rtsp-ice-d-m, SDP", + doi="10.17487/RFC7825", + } + +@misc{rfc7826, + author="H. Schulzrinne and A. Rao and R. Lanphier and M. Westerlund and M. {Stiemerling (Ed.)}", + title="{Real-Time Streaming Protocol Version 2.0}", + howpublished="RFC 7826 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7826", + pages="1--318", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7826.txt", + key="RFC 7826", + abstract={This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326. 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).}, + keywords="mmusic, RTSP, RTSP/2.0, real-time streaming protocol", + doi="10.17487/RFC7826", + } + +@misc{rfc7827, + author="L. Eggert", + title="{The Role of the IRTF Chair}", + howpublished="RFC 7827 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7827", + pages="1--7", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7827.txt", + key="RFC 7827", + abstract={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.}, + doi="10.17487/RFC7827", + } + +@misc{rfc7828, + author="P. Wouters and J. Abley and S. Dickinson and R. Bellis", + title="{The edns-tcp-keepalive EDNS0 Option}", + howpublished="RFC 7828 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7828", + pages="1--11", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7828.txt", + key="RFC 7828", + abstract={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. 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.}, + keywords="long-lived, dnssec, DNS, TCP/IP, transport", + doi="10.17487/RFC7828", + } + +@misc{rfc7829, + author="Y. Nishida and P. Natarajan and A. Caro and P. Amer and K. Nielsen", + title="{SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol}", + howpublished="RFC 7829 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7829", + pages="1--23", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7829.txt", + key="RFC 7829", + abstract={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. 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. 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. The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The proce dures are sender-side only and do not impact the SCTP receiver.}, + keywords="SCTP, Failover, multipath, multihoming, Potentially Failed", + doi="10.17487/RFC7829", + } + +@misc{rfc7830, + author="A. Mayrhofer", + title="{The EDNS(0) Padding Option}", + howpublished="RFC 7830 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7830", + pages="1--5", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7830.txt", + key="RFC 7830", + abstract={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.}, + keywords="Domain Name System, DNS, EDNS, EDNS0, Security, Encryption, Padding", + doi="10.17487/RFC7830", + } + +@misc{rfc7831, + author="J. Howlett and S. Hartman and H. Tschofenig and J. Schaad", + title="{Application Bridging for Federated Access Beyond Web (ABFAB) Architecture}", + howpublished="RFC 7831 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7831", + pages="1--46", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7831.txt", + key="RFC 7831", + abstract={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. 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.}, + keywords="Federated Authentication, AAA, RADIUS, Diameter, GSS-API, EAP, SAML", + doi="10.17487/RFC7831", + } + +@misc{rfc7832, + author="R. {Smith (Ed.)}", + title="{Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases}", + howpublished="RFC 7832 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7832", + pages="1--13", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7832.txt", + key="RFC 7832", + abstract={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.}, + keywords="Federated Authentication, AAA, RADIUS, Diameter, GSS-API, EAP, SASL", + doi="10.17487/RFC7832", + } + +@misc{rfc7833, + author="J. Howlett and S. Hartman and A. {Perez-Mendez (Ed.)}", + title="{A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)}", + howpublished="RFC 7833 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7833", + pages="1--32", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7833.txt", + key="RFC 7833", + abstract={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.}, + keywords="ABFAB, AAA, EAP, RADIUS, SAML", + doi="10.17487/RFC7833", + } + +@misc{rfc7834, + author="D. Saucez and L. Iannone and A. Cabellos and F. Coras", + title="{Locator/ID Separation Protocol (LISP) Impact}", + howpublished="RFC 7834 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7834", + pages="1--18", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7834.txt", + key="RFC 7834", + abstract={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.}, + doi="10.17487/RFC7834", + } + +@misc{rfc7835, + author="D. Saucez and L. Iannone and O. Bonaventure", + title="{Locator/ID Separation Protocol (LISP) Threat Analysis}", + howpublished="RFC 7835 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7835", + pages="1--19", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7835.txt", + key="RFC 7835", + abstract={This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).}, + doi="10.17487/RFC7835", + } + +@misc{rfc7836, + author="S. {Smyshlyaev (Ed.)} and E. Alekseev and I. Oshkin and V. Popov and S. Leontiev and V. Podobaev and D. Belyavsky", + title="{Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012}", + howpublished="RFC 7836 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7836", + pages="1--32", + year=2016, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7836.txt", + key="RFC 7836", + abstract={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. 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.}, + keywords="HMAC, PRF, key agreement, VKO, key exchange, key derivation, KDF, key tree, elliptic curve, Weierstrass, twisted Edwards, TLS, IPsec, IKE, IKEv2", + doi="10.17487/RFC7836", + } + +@misc{rfc7837, + author="S. Krishnan and M. Kuehlewind and B. Briscoe and C. Ralli", + title="{IPv6 Destination Option for Congestion Exposure (ConEx)}", + howpublished="RFC 7837 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7837", + pages="1--13", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7837.txt", + key="RFC 7837", + abstract={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.}, + keywords="Accountability, Traffic Management, Fairness, Resource Sharing, Congestion Control, Quality of Service, QoS, Denial of Service", + doi="10.17487/RFC7837", + } + +@misc{rfc7838, + author="M. Nottingham and P. McManus and J. Reschke", + title="{HTTP Alternative Services}", + howpublished="RFC 7838 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7838", + pages="1--20", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7838.txt", + key="RFC 7838", + abstract={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.}, + keywords="HTTP, ALPN, Alternative Services", + doi="10.17487/RFC7838", + } + +@misc{rfc7839, + author="S. Bhandari and S. Gundavelli and M. Grayson and B. Volz and J. Korhonen", + title="{Access-Network-Identifier Option in DHCP}", + howpublished="RFC 7839 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7839", + pages="1--20", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7839.txt", + key="RFC 7839", + abstract={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.}, + keywords="Operator-Realm, Access-Network-Identifier, Access-Technology-Type, Access-Point, BSSID, Operator-Identifier, DHCPv4, DHCPv6, Local Mobility Anchor (LMA), Proxy Mobile IPv6 (PMIPv6), Service Set Identifier (SSID)", + doi="10.17487/RFC7839", + } + +@misc{rfc7840, + author="J. Winterbottom and H. Tschofenig and L. Liess", + title="{A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol}", + howpublished="RFC 7840 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7840", + pages="1--16", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7840.txt", + key="RFC 7840", + abstract={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.}, + keywords="Emergency, Call, Routing, Location, HELD", + doi="10.17487/RFC7840", + } + +@misc{rfc7841, + author="J. {Halpern (Ed.)} and L. {Daigle (Ed.)} and O. {Kolkman (Ed.)}", + title="{RFC Streams, Headers, and Boilerplates}", + howpublished="RFC 7841 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7841", + pages="1--14", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7841.txt", + key="RFC 7841", + abstract={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.}, + doi="10.17487/RFC7841", + } + +@misc{rfc7842, + author="R. Sparks", + title="{Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool}", + howpublished="RFC 7842 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7842", + pages="1--7", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7842.txt", + key="RFC 7842", + abstract={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.}, + doi="10.17487/RFC7842", + } + +@misc{rfc7843, + author="A. Ripke and R. Winter and T. Dietz and J. Quittek and R. da Silva", + title="{Port Control Protocol (PCP) Third-Party ID Option}", + howpublished="RFC 7843 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7843", + pages="1--14", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7843.txt", + key="RFC 7843", + abstract={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. 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.}, + keywords="PCP, option, third party, ID", + doi="10.17487/RFC7843", + } + +@misc{rfc7844, + author="C. Huitema and T. Mrugalski and S. Krishnan", + title="{Anonymity Profiles for DHCP Clients}", + howpublished="RFC 7844 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7844", + pages="1--26", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7844.txt", + key="RFC 7844", + abstract={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.}, + keywords="DHCP, DHCPv4, DHCPv6, pervasive monitoring, fingerprinting, privacy, Anonymity, MAC Address Randomization, Privacy, Surveillance", + doi="10.17487/RFC7844", + } + +@misc{rfc7845, + author="T. Terriberry and R. Lee and R. Giles", + title="{Ogg Encapsulation for the Opus Audio Codec}", + howpublished="RFC 7845 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7845", + pages="1--35", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7845.txt", + key="RFC 7845", + abstract={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.}, + keywords="container, mapping", + doi="10.17487/RFC7845", + } + +@misc{rfc7846, + author="R. Cruz and M. Nunes and J. Xia and R. {Huang (Ed.)} and J. Taveira and D. Lingli", + title="{Peer-to-Peer Streaming Tracker Protocol (PPSTP)}", + howpublished="RFC 7846 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7846", + pages="1--55", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7846.txt", + key="RFC 7846", + abstract={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.}, + keywords="structured media, peer swarms control, live streaming, video on demand", + doi="10.17487/RFC7846", + } + +@misc{rfc7847, + author="T. {Melia (Ed.)} and S. {Gundavelli (Ed.)}", + title="{Logical-Interface Support for IP Hosts with Multi-Access Support}", + howpublished="RFC 7847 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7847", + pages="1--16", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7847.txt", + key="RFC 7847", + abstract={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.}, + keywords="Logical-interface, virtual-interface, Logical interface", + doi="10.17487/RFC7847", + } + +@misc{rfc7848, + author="G. Lozano", + title="{Mark and Signed Mark Objects Mapping}", + howpublished="RFC 7848 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7848", + pages="1--24", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7848.txt", + key="RFC 7848", + abstract={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). 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. 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.}, + keywords="Trademark Clearinghouse, Signed Mark Data, Signed Mark, Mark, SMD", + doi="10.17487/RFC7848", + } + +@misc{rfc7849, + author="D. Binet and M. Boucadair and A. Vizdal and G. Chen and N. Heatley and R. Chandler and D. Michaud and D. Lopez and W. Haeffner", + title="{An IPv6 Profile for 3GPP Mobile Devices}", + howpublished="RFC 7849 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7849", + pages="1--22", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7849.txt", + key="RFC 7849", + abstract={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). Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.}, + keywords="IPv4 service continuity, address shortage, address depletion, dual-stack, IPv6-only, IPv6 introduction, IPv6 transition, IPv6 migration, cellular networks, mobile networks, PLMN, and IPv6 configuration", + doi="10.17487/RFC7849", + } + +@misc{rfc7850, + author="S. Nandakumar", + title="{Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles}", + howpublished="RFC 7850 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7850", + pages="1--7", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7850.txt", + key="RFC 7850", + abstract={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'.}, + doi="10.17487/RFC7850", + } + +@misc{rfc7851, + author="H. Song and X. Jiang and R. Even and D. Bryan and Y. Sun", + title="{Peer-to-Peer (P2P) Overlay Diagnostics}", + howpublished="RFC 7851 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7851", + pages="1--30", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7851.txt", + key="RFC 7851", + abstract={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.}, + keywords="Real-time Applications and Infrastructure, P2PSIP Working Group, Diagnostics, P2P, P2PSIP", + doi="10.17487/RFC7851", + } + +@misc{rfc7852, + author="R. Gellens and B. Rosen and H. Tschofenig and R. Marshall and J. Winterbottom", + title="{Additional Data Related to an Emergency Call}", + howpublished="RFC 7852 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7852", + pages="1--113", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7852.txt", + key="RFC 7852", + abstract={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. 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.}, + keywords="Additional Call Data, Emergency Services, Call Information", + doi="10.17487/RFC7852", + } + +@misc{rfc7853, + author="S. Martin and S. Tuecke and B. McCollam and M. Lidman", + title="{A URN Namespace for Globus}", + howpublished="RFC 7853 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7853", + pages="1--7", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7853.txt", + key="RFC 7853", + abstract={This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources.}, + doi="10.17487/RFC7853", + } + +@misc{rfc7854, + author="J. {Scudder (Ed.)} and R. Fernando and S. Stuart", + title="{BGP Monitoring Protocol (BMP)}", + howpublished="RFC 7854 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7854", + pages="1--27", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7854.txt", + key="RFC 7854", + abstract={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.}, + keywords="IDR, BGP, GROW, BMP", + doi="10.17487/RFC7854", + } + +@misc{rfc7855, + author="S. {Previdi (Ed.)} and C. {Filsfils (Ed.)} and B. Decraene and S. Litkowski and M. Horneffer and R. Shakir", + title="{Source Packet Routing in Networking (SPRING) Problem Statement and Requirements}", + howpublished="RFC 7855 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7855", + pages="1--19", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7855.txt", + key="RFC 7855", + abstract={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). 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.}, + doi="10.17487/RFC7855", + } + +@misc{rfc7856, + author="Y. Cui and J. Dong and P. Wu and M. Xu and A. Yla-Jaaski", + title="{Softwire Mesh Management Information Base (MIB)}", + howpublished="RFC 7856 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7856", + pages="1--18", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7856.txt", + key="RFC 7856", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing a softwire mesh.}, + keywords="Management Information Base, MIB, SMIv2, mesh", + doi="10.17487/RFC7856", + } + +@misc{rfc7857, + author="R. Penno and S. Perreault and M. {Boucadair (Ed.)} and S. Sivakumar and K. Naito", + title="{Updates to Network Address Translation (NAT) Behavioral Requirements}", + howpublished="RFC 7857 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7857", + pages="1--14", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7857.txt", + key="RFC 7857", + abstract={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). This document updates RFCs 4787, 5382, and 5508.}, + keywords="address sharing, IPv4 service continuity, Carrier Grade NAT, CGN, LSN, NAT traversal, RFC4787, RFC5382, RFC5508, DS-Lite, NAT64, Address depletion", + doi="10.17487/RFC7857", + } + +@misc{rfc7858, + author="Z. Hu and L. Zhu and J. Heidemann and A. Mankin and D. Wessels and P. Hoffman", + title="{Specification for DNS over Transport Layer Security (TLS)}", + howpublished="RFC 7858 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7858", + pages="1--19", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8310", +url="https://www.rfc-editor.org/rfc/rfc7858.txt", + key="RFC 7858", + abstract={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. 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.}, + keywords="DNS encryption, DNS privacy", + doi="10.17487/RFC7858", + } + +@misc{rfc7859, + author="C. Dearlove", + title="{Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols}", + howpublished="RFC 7859 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7859", + pages="1--17", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7859.txt", + key="RFC 7859", + abstract={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.}, + keywords="Mobile Ad hoc Networking (MANET), MANET, TLV, OLSRv2, integrity check value, ICV, ECCSI, elliptic curve, identity-based signature, IBS, identity-based encryption, IBE", + doi="10.17487/RFC7859", + } + +@misc{rfc7860, + author="J. {Merkle (Ed.)} and M. Lochter", + title="{HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3}", + howpublished="RFC 7860 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7860", + pages="1--14", + year=2016, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7860.txt", + key="RFC 7860", + abstract={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.}, + keywords="SNMP, USM, HMAC, SHA-2", + doi="10.17487/RFC7860", + } + +@misc{rfc7861, + author="A. Adamson and N. Williams", + title="{Remote Procedure Call (RPC) Security Version 3}", + howpublished="RFC 7861 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7861", + pages="1--26", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7861.txt", + key="RFC 7861", + abstract={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.}, + keywords="RPCSEC\_GSS, ONC, RPC, GSS, GSS-API, NFS, authentication, privacy, confidentiality, encryption, mechanism, context", + doi="10.17487/RFC7861", + } + +@misc{rfc7862, + author="T. Haynes", + title="{Network File System (NFS) Version 4 Minor Version 2 Protocol}", + howpublished="RFC 7862 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7862", + pages="1--104", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8178", +url="https://www.rfc-editor.org/rfc/rfc7862.txt", + key="RFC 7862", + abstract={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.}, + keywords="NFSv4.2, pNFS, Server-Side Copy, Server-Side Clone, Labeled NFS", + doi="10.17487/RFC7862", + } + +@misc{rfc7863, + author="T. Haynes", + title="{Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description}", + howpublished="RFC 7863 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7863", + pages="1--87", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7863.txt", + key="RFC 7863", + abstract={This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.}, + keywords="NFSv4.2, XDR", + doi="10.17487/RFC7863", + } + +@misc{rfc7864, + author="CJ. {Bernardos (Ed.)}", + title="{Proxy Mobile IPv6 Extensions to Support Flow Mobility}", + howpublished="RFC 7864 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7864", + pages="1--19", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7864.txt", + key="RFC 7864", + abstract={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. 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.}, + keywords="flow mobility, NB-IFOM, PMIPv6, FMI, FMA", + doi="10.17487/RFC7864", + } + +@misc{rfc7865, + author="R. Ravindranath and P. Ravindran and P. Kyzivat", + title="{Session Initiation Protocol (SIP) Recording Metadata}", + howpublished="RFC 7865 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7865", + pages="1--34", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7865.txt", + key="RFC 7865", + abstract={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.}, + doi="10.17487/RFC7865", + } + +@misc{rfc7866, + author="L. Portman and H. {Lum (Ed.)} and C. Eckel and A. Johnston and A. Hutton", + title="{Session Recording Protocol}", + howpublished="RFC 7866 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7866", + pages="1--45", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7866.txt", + key="RFC 7866", + abstract={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.}, + keywords="siprec", + doi="10.17487/RFC7866", + } + +@misc{rfc7867, + author="R. Huang", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications}", + howpublished="RFC 7867 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7867", + pages="1--16", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7867.txt", + key="RFC 7867", + abstract={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.}, + doi="10.17487/RFC7867", + } + +@misc{rfc7868, + author="D. Savage and J. Ng and S. Moore and D. Slice and P. Paluch and R. White", + title="{Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)}", + howpublished="RFC 7868 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7868", + pages="1--80", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7868.txt", + key="RFC 7868", + abstract={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.}, + doi="10.17487/RFC7868", + } + +@misc{rfc7869, + author="D. Warden and I. Iordanov", + title="{The ``vnc'' URI Scheme}", + howpublished="RFC 7869 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7869", + pages="1--25", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7869.txt", + key="RFC 7869", + abstract={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.}, + keywords="RFB, Remote Framebuffer, Virtual Network Computing", + doi="10.17487/RFC7869", + } + +@misc{rfc7870, + author="Y. Fu and S. Jiang and J. Dong and Y. Chen", + title="{Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)}", + howpublished="RFC 7870 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7870", + pages="1--27", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7870.txt", + key="RFC 7870", + abstract={This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).}, + keywords="IPv6", + doi="10.17487/RFC7870", + } + +@misc{rfc7871, + author="C. Contavalli and W. van der Gaast and D. Lawrence and W. Kumari", + title="{Client Subnet in DNS Queries}", + howpublished="RFC 7871 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7871", + pages="1--30", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7871.txt", + key="RFC 7871", + abstract={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.}, + keywords="edns-client-subnet, ECS, DNS geolocation, DNS load-balancing, EDNS, EDNS0, geolocation, privacy", + doi="10.17487/RFC7871", + } + +@misc{rfc7872, + author="F. Gont and J. Linkova and T. Chown and W. Liu", + title="{Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World}", + howpublished="RFC 7872 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7872", + pages="1--15", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7872.txt", + key="RFC 7872", + abstract={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.}, + keywords="packet drops", + doi="10.17487/RFC7872", + } + +@misc{rfc7873, + author="D. {Eastlake 3rd} and M. Andrews", + title="{Domain Name System (DNS) Cookies}", + howpublished="RFC 7873 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7873", + pages="1--25", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7873.txt", + key="RFC 7873", + abstract={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.)}, + keywords="denial of service, forgery, cache poisoning, off-path", + doi="10.17487/RFC7873", + } + +@misc{rfc7874, + author="JM. Valin and C. Bran", + title="{WebRTC Audio Codec and Processing Requirements}", + howpublished="RFC 7874 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7874", + pages="1--7", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7874.txt", + key="RFC 7874", + abstract={This document outlines the audio codec and processing requirements for WebRTC endpoints.}, + doi="10.17487/RFC7874", + } + +@misc{rfc7875, + author="S. {Proust (Ed.)}", + title="{Additional WebRTC Audio Codecs for Interoperability}", + howpublished="RFC 7875 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7875", + pages="1--12", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7875.txt", + key="RFC 7875", + abstract={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. This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.}, + keywords="WebRTC, audio, codec, G.722, AMR, AMR-WB", + doi="10.17487/RFC7875", + } + +@misc{rfc7876, + author="S. Bryant and S. Sivabalan and S. Soni", + title="{UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks}", + howpublished="RFC 7876 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7876", + pages="1--10", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7876.txt", + key="RFC 7876", + abstract={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.}, + keywords="MPLS", + doi="10.17487/RFC7876", + } + +@misc{rfc7877, + author="K. Cartwright and V. Bhatia and S. Ali and D. Schwartz", + title="{Session Peering Provisioning Framework (SPPF)}", + howpublished="RFC 7877 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7877", + pages="1--57", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7877.txt", + key="RFC 7877", + abstract={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.}, + keywords="SPPP, SIP, Peering, SED, Provisioning", + doi="10.17487/RFC7877", + } + +@misc{rfc7878, + author="K. Cartwright and V. Bhatia and J-F. Mule and A. Mayrhofer", + title="{Session Peering Provisioning (SPP) Protocol over SOAP}", + howpublished="RFC 7878 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7878", + pages="1--83", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7878.txt", + key="RFC 7878", + abstract={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.}, + keywords="SPPP, SIP, Peering, SED, Provisioning", + doi="10.17487/RFC7878", + } + +@misc{rfc7879, + author="R. Ravindranath and T. Reddy and G. Salgueiro and V. Pascual and P. Ravindran", + title="{DTLS-SRTP Handling in SIP Back-to-Back User Agents}", + howpublished="RFC 7879 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7879", + pages="1--13", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7879.txt", + key="RFC 7879", + abstract={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.}, + keywords="Session Initiation Protocol, B2BUA, Secure Real-time Transport, Datagram Transport Layer Security", + doi="10.17487/RFC7879", + } + +@misc{rfc7880, + author="C. Pignataro and D. Ward and N. Akiya and M. Bhatia and S. Pallagatti", + title="{Seamless Bidirectional Forwarding Detection (S-BFD)}", + howpublished="RFC 7880 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7880", + pages="1--24", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7880.txt", + key="RFC 7880", + abstract={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. This document updates RFC 5880.}, + keywords="BFD, seamless BFD, negotiation free, segment routing, IP", + doi="10.17487/RFC7880", + } + +@misc{rfc7881, + author="C. Pignataro and D. Ward and N. Akiya", + title="{Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS}", + howpublished="RFC 7881 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7881", + pages="1--8", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7881.txt", + key="RFC 7881", + abstract={This document defines procedures for using Seamless Bidirectional Forwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments.}, + keywords="BFD, seamless BFD, negotiation free, label verification, segment routing, IP", + doi="10.17487/RFC7881", + } + +@misc{rfc7882, + author="S. Aldrin and C. Pignataro and G. Mirsky and N. Kumar", + title="{Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases}", + howpublished="RFC 7882 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7882", + pages="1--15", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7882.txt", + key="RFC 7882", + abstract={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. 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.}, + keywords="BFD, seamless BFD, negotiation free, label verification, segment routing, IP", + doi="10.17487/RFC7882", + } + +@misc{rfc7883, + author="L. Ginsberg and N. Akiya and M. Chen", + title="{Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS}", + howpublished="RFC 7883 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7883", + pages="1--5", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7883.txt", + key="RFC 7883", + abstract={This document defines a means of advertising one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators using the IS-IS Router CAPABILITY TLV.}, + doi="10.17487/RFC7883", + } + +@misc{rfc7884, + author="C. Pignataro and M. Bhatia and S. Aldrin and T. Ranganath", + title="{OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators}", + howpublished="RFC 7884 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7884", + pages="1--7", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7884.txt", + key="RFC 7884", + abstract={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.}, + keywords="BFD, seamless BFD, negotiation free, label verification, segment routing, IP", + doi="10.17487/RFC7884", + } + +@misc{rfc7885, + author="V. Govindan and C. Pignataro", + title="{Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)}", + howpublished="RFC 7885 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7885", + pages="1--11", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7885.txt", + key="RFC 7885", + abstract={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). This document updates RFC 5885 by extending the CV Type values and the capability selection.}, + keywords="RFC5885, L2TPv3, VCCV, S-BFD", + doi="10.17487/RFC7885", + } + +@misc{rfc7886, + author="V. Govindan and C. Pignataro", + title="{Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3)}", + howpublished="RFC 7886 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7886", + pages="1--6", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7886.txt", + key="RFC 7886", + abstract={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).}, + keywords="S-BFD", + doi="10.17487/RFC7886", + } + +@misc{rfc7887, + author="S. Venaas and J. Arango and I. Kouvelas", + title="{Hierarchical Join/Prune Attributes}", + howpublished="RFC 7887 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7887", + pages="1--8", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7887.txt", + key="RFC 7887", + abstract={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.}, + keywords="multicast, pim", + doi="10.17487/RFC7887", + } + +@misc{rfc7888, + author="A. {Melnikov (Ed.)}", + title="{IMAP4 Non-synchronizing Literals}", + howpublished="RFC 7888 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7888", + pages="1--9", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7888.txt", + key="RFC 7888", + abstract={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. 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. This document obsoletes RFC 2088.}, + keywords="IMAP, LITERAL+, LITERAL-, APPENDLIMIT", + doi="10.17487/RFC7888", + } + +@misc{rfc7889, + author="J. SrimushnamBoovaraghamoorthy and N. Bisht", + title="{The IMAP APPENDLIMIT Extension}", + howpublished="RFC 7889 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7889", + pages="1--7", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7889.txt", + key="RFC 7889", + abstract={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.}, + doi="10.17487/RFC7889", + } + +@misc{rfc7890, + author="D. Bryan and P. Matthews and E. Shim and D. Willis and S. Dawkins", + title="{Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)}", + howpublished="RFC 7890 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7890", + pages="1--19", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7890.txt", + key="RFC 7890", + abstract={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.}, + keywords="Distributed Database, P2PSIP, SIP, Server-less, DHT", + doi="10.17487/RFC7890", + } + +@misc{rfc7891, + author="J. Asghar and IJ. {Wijnands (Ed.)} and S. Krishnaswamy and A. Karan and V. Arya", + title="{Explicit Reverse Path Forwarding (RPF) Vector}", + howpublished="RFC 7891 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7891", + pages="1--9", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7891.txt", + key="RFC 7891", + abstract={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. 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.}, + keywords="Path diversity, MoFRR, Maximally redundant paths", + doi="10.17487/RFC7891", + } + +@misc{rfc7892, + author="Z. Ali and A. Bonfanti and M. Hartley and F. Zhang", + title="{IANA Allocation Procedures for the GMPLS OTN Signal Type Registry}", + howpublished="RFC 7892 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7892", + pages="1--4", + year=2016, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7892.txt", + key="RFC 7892", + abstract={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.}, + doi="10.17487/RFC7892", + } + +@misc{rfc7893, + author="Y(J) Stein and D. Black and B. Briscoe", + title="{Pseudowire Congestion Considerations}", + howpublished="RFC 7893 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7893", + pages="1--27", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7893.txt", + key="RFC 7893", + abstract={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 d o 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.}, + keywords="pseudowire, congestion, TCP friendliness", + doi="10.17487/RFC7893", + } + +@misc{rfc7894, + author="M. Pritikin and C. Wallace", + title="{Alternative Challenge Password Attributes for Enrollment over Secure Transport}", + howpublished="RFC 7894 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7894", + pages="1--10", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7894.txt", + key="RFC 7894", + abstract={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.}, + keywords="Enrollment over Secure Transport", + doi="10.17487/RFC7894", + } + +@misc{rfc7895, + author="A. Bierman and M. Bjorklund and K. Watsen", + title="{YANG Module Library}", + howpublished="RFC 7895 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7895", + pages="1--13", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7895.txt", + key="RFC 7895", + abstract={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.}, + keywords="NETCONF, RESTCONF", + doi="10.17487/RFC7895", + } + +@misc{rfc7896, + author="D. Dhody", + title="{Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)}", + howpublished="RFC 7896 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7896", + pages="1--5", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7896.txt", + key="RFC 7896", + abstract={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. This document updates RFC 5440 regarding the IRO specification.}, + keywords="PCEP, PCE, IRO", + doi="10.17487/RFC7896", + } + +@misc{rfc7897, + author="D. Dhody and U. Palle and R. Casellas", + title="{Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)}", + howpublished="RFC 7897 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7897", + pages="1--35", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7897.txt", + key="RFC 7897", + abstract={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.}, + keywords="PCEP, PCE, domain, subobjects", + doi="10.17487/RFC7897", + } + +@misc{rfc7898, + author="D. Dhody and U. Palle and V. Kondreddy and R. Casellas", + title="{Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)}", + howpublished="RFC 7898 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7898", + pages="1--18", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7898.txt", + key="RFC 7898", + abstract={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. 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.}, + keywords="RSVP-TE, domain, subobjects", + doi="10.17487/RFC7898", + } + +@misc{rfc7899, + author="T. {Morin (Ed.)} and S. Litkowski and K. Patel and Z. Zhang and R. Kebler and J. Haas", + title="{Multicast VPN State Damping}", + howpublished="RFC 7899 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7899", + pages="1--18", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7899.txt", + key="RFC 7899", + abstract={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.}, + keywords="dampening, multicast, vpn, damping, bgp, pim", + doi="10.17487/RFC7899", + } + +@misc{rfc7900, + author="Y. {Rekhter (Ed.)} and E. {Rosen (Ed.)} and R. Aggarwal and Y. Cai and T. Morin", + title="{Extranet Multicast in BGP/IP MPLS VPNs}", + howpublished="RFC 7900 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7900", + pages="1--65", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7900.txt", + key="RFC 7900", + abstract={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.}, + keywords="Multicast", + doi="10.17487/RFC7900", + } + +@misc{rfc7901, + author="P. Wouters", + title="{CHAIN Query Requests in DNS}", + howpublished="RFC 7901 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7901", + pages="1--16", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7901.txt", + key="RFC 7901", + abstract={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.}, + keywords="DNSSEC, EDNS0, latency", + doi="10.17487/RFC7901", + } + +@misc{rfc7902, + author="E. Rosen and T. Morin", + title="{Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags}", + howpublished="RFC 7902 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7902", + pages="1--7", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7902.txt", + key="RFC 7902", + abstract={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.}, + doi="10.17487/RFC7902", + } + +@misc{rfc7903, + author="S. Leonard", + title="{Windows Image Media Types}", + howpublished="RFC 7903 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7903", + pages="1--12", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7903.txt", + key="RFC 7903", + abstract={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.}, + doi="10.17487/RFC7903", + } + +@misc{rfc7904, + author="C. Jennings and B. Lowekamp and E. Rescorla and S. Baset and H. Schulzrinne and T. {Schmidt (Ed.)}", + title="{A SIP Usage for REsource LOcation And Discovery (RELOAD)}", + howpublished="RFC 7904 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7904", + pages="1--20", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7904.txt", + key="RFC 7904", + abstract={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.}, + keywords="p2psip, p2p, sip, reload, peer-to-peer, session initiation, distributed session management, overlay network, SIP registrar", + doi="10.17487/RFC7904", + } + +@misc{rfc7905, + author="A. Langley and W. Chang and N. Mavrogiannopoulos and J. Strombergson and S. Josefsson", + title="{ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)}", + howpublished="RFC 7905 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7905", + pages="1--8", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7905.txt", + key="RFC 7905", + abstract={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. This document updates RFCs 5246 and 6347.}, + keywords="AEAD, DTLS", + doi="10.17487/RFC7905", + } + +@misc{rfc7906, + author="P. Timmel and R. Housley and S. Turner", + title="{NSA's Cryptographic Message Syntax (CMS) Key Management Attributes}", + howpublished="RFC 7906 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7906", + pages="1--68", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7906.txt", + key="RFC 7906", + abstract={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.}, + doi="10.17487/RFC7906", + } + +@misc{rfc7908, + author="K. Sriram and D. Montgomery and D. McPherson and E. Osterweil and B. Dickson", + title="{Problem Definition and Classification of BGP Route Leaks}", + howpublished="RFC 7908 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7908", + pages="1--11", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7908.txt", + key="RFC 7908", + abstract={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.}, + keywords="BGP, BGPSEC, Route Leak, Route Leak Detection, Route Leak Mitigation, BGP Security", + doi="10.17487/RFC7908", + } + +@misc{rfc7909, + author="R. Kisteleki and B. Haberman", + title="{Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures}", + howpublished="RFC 7909 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7909", + pages="1--14", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7909.txt", + key="RFC 7909", + abstract={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.}, + doi="10.17487/RFC7909", + } + +@misc{rfc7910, + author="W. Zhou", + title="{Interoperability between the Virtual Router Redundancy Protocol and PIM}", + howpublished="RFC 7910 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7910", + pages="1--6", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7910.txt", + key="RFC 7910", + abstract={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.}, + doi="10.17487/RFC7910", + } + +@misc{rfc7911, + author="D. Walton and A. Retana and E. Chen and J. Scudder", + title="{Advertisement of Multiple Paths in BGP}", + howpublished="RFC 7911 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7911", + pages="1--8", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7911.txt", + key="RFC 7911", + abstract={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.}, + keywords="border gateway protocol", + doi="10.17487/RFC7911", + } + +@misc{rfc7912, + author="A. Melnikov", + title="{Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure}", + howpublished="RFC 7912 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7912", + pages="1--11", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7912.txt", + key="RFC 7912", + abstract={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.}, + keywords="MMHS, S/MIME, MIXER, email", + doi="10.17487/RFC7912", + } + +@misc{rfc7913, + author="C. Holmberg", + title="{P-Access-Network-Info ABNF Update}", + howpublished="RFC 7913 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7913", + pages="1--4", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7913.txt", + key="RFC 7913", + abstract={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.}, + keywords="Transport, PANI, ABNF, P-Access-Network-Info, 3GPP, IMS", + doi="10.17487/RFC7913", + } + +@misc{rfc7914, + author="C. Percival and S. Josefsson", + title="{The scrypt Password-Based Key Derivation Function}", + howpublished="RFC 7914 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7914", + pages="1--16", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7914.txt", + key="RFC 7914", + abstract={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.}, + keywords="PBKDF", + doi="10.17487/RFC7914", + } + +@misc{rfc7915, + author="C. Bao and X. Li and F. Baker and T. Anderson and F. Gont", + title="{IP/ICMP Translation Algorithm}", + howpublished="RFC 7915 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7915", + pages="1--34", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7915.txt", + key="RFC 7915", + abstract={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.}, + keywords="SIIT, internet, protocol, control, message, IPv4, IPv6, Stateless IP/ICMP Translation Algorithm, RFC6145bis", + doi="10.17487/RFC7915", + } + +@misc{rfc7916, + author="S. {Litkowski (Ed.)} and B. Decraene and C. Filsfils and K. Raza and M. Horneffer and P. Sarkar", + title="{Operational Management of Loop-Free Alternates}", + howpublished="RFC 7916 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7916", + pages="1--31", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7916.txt", + key="RFC 7916", + abstract={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. This proposal is also applicable to remote-LFA solutions.}, + keywords="IGP, LFA, policy, FRR, fast reroute, network planning", + doi="10.17487/RFC7916", + } + +@misc{rfc7917, + author="P. {Sarkar (Ed.)} and H. Gredler and S. Hegde and S. Litkowski and B. Decraene", + title="{Advertising Node Administrative Tags in IS-IS}", + howpublished="RFC 7917 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7917", + pages="1--11", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7917.txt", + key="RFC 7917", + abstract={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.}, + keywords="IGP, IS-IS, Admin-Tag, Traffic Engineering", + doi="10.17487/RFC7917", + } + +@misc{rfc7918, + author="A. Langley and N. Modadugu and B. Moeller", + title="{Transport Layer Security (TLS) False Start}", + howpublished="RFC 7918 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7918", + pages="1--11", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7918.txt", + key="RFC 7918", + abstract={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.}, + doi="10.17487/RFC7918", + } + +@misc{rfc7919, + author="D. Gillmor", + title="{Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)}", + howpublished="RFC 7919 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7919", + pages="1--29", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7919.txt", + key="RFC 7919", + abstract={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. 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).}, + keywords="Diffie-Hellman, Discrete Logarithm, Finite Field, Transport Layer Security, TLS, Negotiation", + doi="10.17487/RFC7919", + } + +@misc{rfc7920, + author="A. {Atlas (Ed.)} and T. {Nadeau (Ed.)} and D. Ward", + title="{Problem Statement for the Interface to the Routing System}", + howpublished="RFC 7920 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7920", + pages="1--12", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7920.txt", + key="RFC 7920", + abstract={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. This document proposes meeting this need via an Interface to the Routing System (I2RS).}, + doi="10.17487/RFC7920", + } + +@misc{rfc7921, + author="A. Atlas and J. Halpern and S. Hares and D. Ward and T. Nadeau", + title="{An Architecture for the Interface to the Routing System}", + howpublished="RFC 7921 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7921", + pages="1--40", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7921.txt", + key="RFC 7921", + abstract={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).}, + doi="10.17487/RFC7921", + } + +@misc{rfc7922, + author="J. Clarke and G. Salgueiro and C. Pignataro", + title="{Interface to the Routing System (I2RS) Traceability: Framework and Information Model}", + howpublished="RFC 7922 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7922", + pages="1--17", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7922.txt", + key="RFC 7922", + abstract={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.}, + keywords="I2RS, I2RS Traceability, I2RS Traceability", + doi="10.17487/RFC7922", + } + +@misc{rfc7923, + author="E. Voit and A. Clemm and A. Gonzalez Prieto", + title="{Requirements for Subscription to YANG Datastores}", + howpublished="RFC 7923 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7923", + pages="1--18", + year=2016, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7923.txt", + key="RFC 7923", + abstract={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.}, + keywords="pub/sub, push updates", + doi="10.17487/RFC7923", + } + +@misc{rfc7924, + author="S. Santesson and H. Tschofenig", + title="{Transport Layer Security (TLS) Cached Information Extension}", + howpublished="RFC 7924 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7924", + pages="1--19", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7924.txt", + key="RFC 7924", + abstract={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). 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.}, + keywords="TLS Cached Information, TLS Cached Info, TLS Extension, TLS Optimization", + doi="10.17487/RFC7924", + } + +@misc{rfc7925, + author="H. {Tschofenig (Ed.)} and T. Fossati", + title="{Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things}", + howpublished="RFC 7925 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7925", + pages="1--61", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7925.txt", + key="RFC 7925", + abstract={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. 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.}, + keywords="Internet of Things Security, TLS Profile, DTLS Profile, IoT Security, DTLS over SMS", + doi="10.17487/RFC7925", + } + +@misc{rfc7926, + author="A. {Farrel (Ed.)} and J. Drake and N. Bitar and G. Swallow and D. Ceccarelli and X. Zhang", + title="{Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks}", + howpublished="RFC 7926 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7926", + pages="1--67", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7926.txt", + key="RFC 7926", + abstract={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. 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. 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.}, + keywords="Abstract link, Abstract node, Abstraction, Abstraction layer, Aggregation, Virtual node, Virtual link", + doi="10.17487/RFC7926", + } + +@misc{rfc7927, + author="D. {Kutscher (Ed.)} and S. Eum and K. Pentikousis and I. Psaras and D. Corujo and D. Saucez and T. Schmidt and M. Waehlisch", + title="{Information-Centric Networking (ICN) Research Challenges}", + howpublished="RFC 7927 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7927", + pages="1--38", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7927.txt", + key="RFC 7927", + abstract={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. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).}, + keywords="Information centric networking", + doi="10.17487/RFC7927", + } + +@misc{rfc7928, + author="N. {Kuhn (Ed.)} and P. {Natarajan (Ed.)} and N. {Khademi (Ed.)} and D. Ros", + title="{Characterization Guidelines for Active Queue Management (AQM)}", + howpublished="RFC 7928 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7928", + pages="1--37", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7928.txt", + key="RFC 7928", + abstract={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.}, + doi="10.17487/RFC7928", + } + +@misc{rfc7929, + author="P. Wouters", + title="{DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP}", + howpublished="RFC 7929 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7929", + pages="1--20", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7929.txt", + key="RFC 7929", + abstract={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.}, + keywords="opportunistic security, encrypted email", + doi="10.17487/RFC7929", + } + +@misc{rfc7930, + author="S. Hartman", + title="{Larger Packets for RADIUS over TCP}", + howpublished="RFC 7930 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7930", + pages="1--10", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7930.txt", + key="RFC 7930", + abstract={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.}, + keywords="ABFAB", + doi="10.17487/RFC7930", + } + +@misc{rfc7931, + author="D. {Noveck (Ed.)} and P. Shivam and C. Lever and B. Baker", + title="{NFSv4.0 Migration: Specification Update}", + howpublished="RFC 7931 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7931", + pages="1--55", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7931.txt", + key="RFC 7931", + abstract={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.}, + doi="10.17487/RFC7931", + } + +@misc{rfc7932, + author="J. Alakuijala and Z. Szabadka", + title="{Brotli Compressed Data Format}", + howpublished="RFC 7932 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7932", + pages="1--128", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7932.txt", + key="RFC 7932", + abstract={This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.}, + doi="10.17487/RFC7932", + } + +@misc{rfc7933, + author="C. {Westphal (Ed.)} and S. Lederer and D. Posch and C. Timmerer and A. Azgin and W. Liu and C. Mueller and A. Detti and D. Corujo and J. Wang and M. Montpetit and N. Murray", + title="{Adaptive Video Streaming over Information-Centric Networking (ICN)}", + howpublished="RFC 7933 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7933", + pages="1--40", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7933.txt", + key="RFC 7933", + abstract={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.}, + keywords="ICN, CCN, NDN, DASH, adaptive video streaming, scalable video streaming, IPTV, P2P, DRM", + doi="10.17487/RFC7933", + } + +@misc{rfc7934, + author="L. Colitti and V. Cerf and S. Cheshire and D. Schinazi", + title="{Host Address Availability Recommendations}", + howpublished="RFC 7934 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7934", + pages="1--15", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7934.txt", + key="RFC 7934", + abstract={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.}, + keywords="IPv6, IPv4, SLAAC, DHCPv6, Prefix Delegation, NAT, NAT64, 464XLAT, /64, Address Assignment, Addressing", + doi="10.17487/RFC7934", + } + +@misc{rfc7935, + author="G. Huston and G. {Michaelson (Ed.)}", + title="{The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure}", + howpublished="RFC 7935 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7935", + pages="1--9", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8208", +url="https://www.rfc-editor.org/rfc/rfc7935.txt", + key="RFC 7935", + abstract={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.}, + doi="10.17487/RFC7935", + } + +@misc{rfc7936, + author="T. Hardie", + title="{Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry}", + howpublished="RFC 7936 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7936", + pages="1--3", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7936.txt", + key="RFC 7936", + abstract={This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455.}, + doi="10.17487/RFC7936", + } + +@misc{rfc7937, + author="F. Le {Faucheur (Ed.)} and G. {Bertrand (Ed.)} and I. {Oprescu (Ed.)} and R. Peterkofsky", + title="{Content Distribution Network Interconnection (CDNI) Logging Interface}", + howpublished="RFC 7937 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7937", + pages="1--63", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7937.txt", + key="RFC 7937", + abstract={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.}, + keywords="CDNI, Logging, CDN, Interconnection", + doi="10.17487/RFC7937", + } + +@misc{rfc7938, + author="P. Lapukhov and A. Premji and J. {Mitchell (Ed.)}", + title="{Use of BGP for Routing in Large-Scale Data Centers}", + howpublished="RFC 7938 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7938", + pages="1--35", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7938.txt", + key="RFC 7938", + abstract={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.}, + keywords="BGP, ECMP, Clos", + doi="10.17487/RFC7938", + } + +@misc{rfc7939, + author="U. Herberg and R. Cole and I. Chakeres and T. Clausen", + title="{Definition of Managed Objects for the Neighborhood Discovery Protocol}", + howpublished="RFC 7939 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7939", + pages="1--72", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7939.txt", + key="RFC 7939", + abstract={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.}, + keywords="Network Management, Management Information Base, MIB, SMIv2, Routing, Neighbor Discovery, MANET, NHDP-MIB", + doi="10.17487/RFC7939", + } + +@misc{rfc7940, + author="K. Davies and A. Freytag", + title="{Representing Label Generation Rulesets Using XML}", + howpublished="RFC 7940 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7940", + pages="1--82", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7940.txt", + key="RFC 7940", + abstract={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.}, + keywords="IDN, LGR, IDN table, variant table", + doi="10.17487/RFC7940", + } + +@misc{rfc7941, + author="M. Westerlund and B. Burman and R. Even and M. Zanaty", + title="{RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items}", + howpublished="RFC 7941 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7941", + pages="1--17", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7941.txt", + key="RFC 7941", + abstract={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.}, + doi="10.17487/RFC7941", + } + +@misc{rfc7942, + author="Y. Sheffer and A. Farrel", + title="{Improving Awareness of Running Code: The Implementation Status Section}", + howpublished="RFC 7942 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7942", + pages="1--8", + year=2016, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7942.txt", + key="RFC 7942", + abstract={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. 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.}, + doi="10.17487/RFC7942", + } + +@misc{rfc7943, + author="F. Gont and W. Liu", + title="{A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}", + howpublished="RFC 7943 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7943", + pages="1--10", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7943.txt", + key="RFC 7943", + abstract={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.}, + keywords="security, privacy, resiliency, attack, scanning, tracking", + doi="10.17487/RFC7943", + } + +@misc{rfc7944, + author="S. Donovan", + title="{Diameter Routing Message Priority}", + howpublished="RFC 7944 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7944", + pages="1--18", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7944.txt", + key="RFC 7944", + abstract={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.}, + keywords="Diameter, Overload", + doi="10.17487/RFC7944", + } + +@misc{rfc7945, + author="K. {Pentikousis (Ed.)} and B. Ohlman and E. Davies and S. Spirou and G. Boggia", + title="{Information-Centric Networking: Evaluation and Security Considerations}", + howpublished="RFC 7945 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7945", + pages="1--38", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7945.txt", + key="RFC 7945", + abstract={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.}, + doi="10.17487/RFC7945", + } + +@misc{rfc7946, + author="H. Butler and M. Daly and A. Doyle and S. Gillies and S. Hagen and T. Schaub", + title="{The GeoJSON Format}", + howpublished="RFC 7946 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7946", + pages="1--28", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7946.txt", + key="RFC 7946", + abstract={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.}, + keywords="JSON, Geospatial, JavaScript Object Notation", + doi="10.17487/RFC7946", + } + +@misc{rfc7947, + author="E. Jasinska and N. Hilliard and R. Raszuk and N. Bakker", + title="{Internet Exchange BGP Route Server}", + howpublished="RFC 7947 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7947", + pages="1--12", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7947.txt", + key="RFC 7947", + abstract={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.}, + keywords="IDR", + doi="10.17487/RFC7947", + } + +@misc{rfc7948, + author="N. Hilliard and E. Jasinska and R. Raszuk and N. Bakker", + title="{Internet Exchange BGP Route Server Operations}", + howpublished="RFC 7948 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7948", + pages="1--15", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7948.txt", + key="RFC 7948", + abstract={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. 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. This document describes operational considerations for multilateral interconnections at IXPs.}, + keywords="GROW", + doi="10.17487/RFC7948", + } + +@misc{rfc7949, + author="I. Chen and A. Lindem and R. Atkinson", + title="{OSPFv3 over IPv4 for IPv6 Transition}", + howpublished="RFC 7949 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7949", + pages="1--11", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7949.txt", + key="RFC 7949", + abstract={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.}, + keywords="IPv4 transport, OSPFv3 transition", + doi="10.17487/RFC7949", + } + +@misc{rfc7950, + author="M. {Bjorklund (Ed.)}", + title="{The YANG 1.1 Data Modeling Language}", + howpublished="RFC 7950 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7950", + pages="1--217", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8342", +url="https://www.rfc-editor.org/rfc/rfc7950.txt", + key="RFC 7950", + abstract={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).}, + keywords="NETCONF, XML, data modeling", + doi="10.17487/RFC7950", + } + +@misc{rfc7951, + author="L. Lhotka", + title="{JSON Encoding of Data Modeled with YANG}", + howpublished="RFC 7951 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7951", + pages="1--20", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7951.txt", + key="RFC 7951", + abstract={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.}, + keywords="I-JSON, RESTCONF", + doi="10.17487/RFC7951", + } + +@misc{rfc7952, + author="L. Lhotka", + title="{Defining and Using Metadata with YANG}", + howpublished="RFC 7952 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7952", + pages="1--21", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7952.txt", + key="RFC 7952", + abstract={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.}, + keywords="metadata annotations, YANG extension", + doi="10.17487/RFC7952", + } + +@misc{rfc7953, + author="C. Daboo and M. Douglass", + title="{Calendar Availability}", + howpublished="RFC 7953 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7953", + pages="1--24", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7953.txt", + key="RFC 7953", + abstract={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. 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.}, + keywords="availability, calendaring, free-busy, iCalendar, CalDAV", + doi="10.17487/RFC7953", + } + +@misc{rfc7954, + author="L. Iannone and D. Lewis and D. Meyer and V. Fuller", + title="{Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block}", + howpublished="RFC 7954 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7954", + pages="1--12", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7954.txt", + key="RFC 7954", + abstract={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.}, + doi="10.17487/RFC7954", + } + +@misc{rfc7955, + author="L. Iannone and R. Jorgensen and D. Conrad and G. Huston", + title="{Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block}", + howpublished="RFC 7955 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7955", + pages="1--10", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7955.txt", + key="RFC 7955", + abstract={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.}, + doi="10.17487/RFC7955", + } + +@misc{rfc7956, + author="W. Hao and Y. Li and A. Qu and M. Durrani and P. Sivamurugan", + title="{Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway}", + howpublished="RFC 7956 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7956", + pages="1--28", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7956.txt", + key="RFC 7956", + abstract={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: 1. Sub-optimum forwarding paths for inter-subnet traffic. 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. 3. A traffic bottleneck at the gateway. This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.}, + keywords="tenant, data center", + doi="10.17487/RFC7956", + } + +@misc{rfc7957, + author="B. {Campbell (Ed.)} and A. Cooper and B. Leiba", + title="{DISPATCH-Style Working Groups and the SIP Change Process}", + howpublished="RFC 7957 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="7957", + pages="1--6", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7957.txt", + key="RFC 7957", + abstract={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.}, + keywords="dispatch, RAI, ART, sip-change", + doi="10.17487/RFC7957", + } + +@misc{rfc7958, + author="J. Abley and J. Schlyter and G. Bailey and P. Hoffman", + title="{DNSSEC Trust Anchor Publication for the Root Zone}", + howpublished="RFC 7958 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7958", + pages="1--14", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7958.txt", + key="RFC 7958", + abstract={The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). 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.}, + keywords="DNS, ICANN, IANA, KSK", + doi="10.17487/RFC7958", + } + +@misc{rfc7959, + author="C. Bormann and Z. {Shelby (Ed.)}", + title="{Block-Wise Transfers in the Constrained Application Protocol (CoAP)}", + howpublished="RFC 7959 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7959", + pages="1--37", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8323", +url="https://www.rfc-editor.org/rfc/rfc7959.txt", + key="RFC 7959", + abstract={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. 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. 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.}, + keywords="CoAP, Constrained Application Protocol, REST, Internet of Things, IoT, Smart Object, Embedded Internet, Constrained Node", + doi="10.17487/RFC7959", + } + +@misc{rfc7960, + author="F. {Martin (Ed.)} and E. {Lear (Ed.)} and T. Draegen. Ed. and E. {Zwicky (Ed.)} and K. {Andersen (Ed.)}", + title="{Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows}", + howpublished="RFC 7960 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7960", + pages="1--27", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7960.txt", + key="RFC 7960", + abstract={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.}, + keywords="DMARC, SMTP, DKIM, SPF", + doi="10.17487/RFC7960", + } + +@misc{rfc7961, + author="D. {Eastlake 3rd} and L. Yizhou", + title="{Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV}", + howpublished="RFC 7961 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7961", + pages="1--24", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7961.txt", + key="RFC 7961", + abstract={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.}, + keywords="reachability, AFN, template", + doi="10.17487/RFC7961", + } + +@misc{rfc7962, + author="J. {Saldana (Ed.)} and A. Arcia-Moret and B. Braem and E. Pietrosemoli and A. Sathiaseelan and M. Zennaro", + title="{Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures}", + howpublished="RFC 7962 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7962", + pages="1--43", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7962.txt", + key="RFC 7962", + abstract={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. The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties. 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.}, + keywords="alternative network deployments, community networks, user-centric networks, Wireless Internet Service Providers, mainstream network, gaia, global access to the Internet for all", + doi="10.17487/RFC7962", + } + +@misc{rfc7963, + author="Z. Ali and A. Bonfanti and M. Hartley and F. Zhang", + title="{RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs)}", + howpublished="RFC 7963 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7963", + pages="1--5", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7963.txt", + key="RFC 7963", + abstract={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.}, + keywords="GMPLS", + doi="10.17487/RFC7963", + } + +@misc{rfc7964, + author="D. Walton and A. Retana and E. Chen and J. Scudder", + title="{Solutions for BGP Persistent Route Oscillation}", + howpublished="RFC 7964 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7964", + pages="1--9", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7964.txt", + key="RFC 7964", + abstract={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.}, + keywords="BGP churn oscillation", + doi="10.17487/RFC7964", + } + +@misc{rfc7965, + author="M. Chen and W. Cao and A. Takacs and P. Pan", + title="{LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels}", + howpublished="RFC 7965 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7965", + pages="1--16", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7965.txt", + key="RFC 7965", + abstract={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.}, + doi="10.17487/RFC7965", + } + +@misc{rfc7966, + author="H. Tschofenig and J. {Korhonen (Ed.)} and G. Zorn and K. Pillay", + title="{Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements}", + howpublished="RFC 7966 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7966", + pages="1--11", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7966.txt", + key="RFC 7966", + abstract={This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).}, + keywords="Diameter, End-to-End Security", + doi="10.17487/RFC7966", + } + +@misc{rfc7967, + author="A. Bhattacharyya and S. Bandyopadhyay and A. Pal and T. Bose", + title="{Constrained Application Protocol (CoAP) Option for No Server Response}", + howpublished="RFC 7967 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7967", + pages="1--18", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7967.txt", + key="RFC 7967", + abstract={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. 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 serv er 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.}, + keywords="No-Response", + doi="10.17487/RFC7967", + } + +@misc{rfc7968, + author="Y. Li and D. {Eastlake 3rd} and W. Hao and H. Chen and S. Chatterjee", + title="{Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data}", + howpublished="RFC 7968 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7968", + pages="1--22", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7968.txt", + key="RFC 7968", + abstract={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. 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 to tal amount of pruning information so that it can more easily be accommodated by fast-path hardware.}, + keywords="VLAN, fine-grained label, multicast", + doi="10.17487/RFC7968", + } + +@misc{rfc7969, + author="T. Lemon and T. Mrugalski", + title="{Customizing DHCP Configuration on the Basis of Network Topology}", + howpublished="RFC 7969 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7969", + pages="1--20", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7969.txt", + key="RFC 7969", + abstract={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.}, + keywords="dhcpv4, dhcpv6, relay-agents (relay agents), multiple subnets, subnets, links, prefixes", + doi="10.17487/RFC7969", + } + +@misc{rfc7970, + author="R. Danyliw", + title="{The Incident Object Description Exchange Format Version 2}", + howpublished="RFC 7970 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7970", + pages="1--172", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7970.txt", + key="RFC 7970", + abstract={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.}, + keywords="incident data format, incident report, cyber threat indicators, computer security incident, computer security incident response team, CSIRT, CERT, security data sharing, Computer Network Defense Service Provider, CNDSP, information sharing, automated information sharing, cyber indicators", + doi="10.17487/RFC7970", + } + +@misc{rfc7971, + author="M. Stiemerling and S. Kiesel and M. Scharf and H. Seidel and S. Previdi", + title="{Application-Layer Traffic Optimization (ALTO) Deployment Considerations}", + howpublished="RFC 7971 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7971", + pages="1--77", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7971.txt", + key="RFC 7971", + abstract={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.}, + doi="10.17487/RFC7971", + } + +@misc{rfc7972, + author="P. Lemieux", + title="{Entertainment Identifier Registry (EIDR) URN Namespace Definition}", + howpublished="RFC 7972 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7972", + pages="1--10", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7972.txt", + key="RFC 7972", + abstract={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. This document obsoletes RFC 7302.}, + keywords="EIDR, Entertainment Identifier Registry, and URN", + doi="10.17487/RFC7972", + } + +@misc{rfc7973, + author="R. Droms and P. Duffy", + title="{Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation}", + howpublished="RFC 7973 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7973", + pages="1--5", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7973.txt", + key="RFC 7973", + abstract={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.}, + keywords="6lowpan, header compression, ethertype", + doi="10.17487/RFC7973", + } + +@misc{rfc7974, + author="B. Williams and M. Boucadair and D. Wing", + title="{An Experimental TCP Option for Host Identification}", + howpublished="RFC 7974 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="7974", + pages="1--20", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7974.txt", + key="RFC 7974", + abstract={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.}, + keywords="Policy enforcement, Address sharing, NAT, Host reveal, Host-ID", + doi="10.17487/RFC7974", + } + +@misc{rfc7975, + author="B. {Niven-Jenkins (Ed.)} and R. van {Brandenburg (Ed.)}", + title="{Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection}", + howpublished="RFC 7975 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7975", + pages="1--35", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7975.txt", + key="RFC 7975", + abstract={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.}, + keywords="HTTP, DNS", + doi="10.17487/RFC7975", + } + +@misc{rfc7976, + author="C. Holmberg and N. Biondic and G. Salgueiro", + title="{Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses}", + howpublished="RFC 7976 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7976", + pages="1--8", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7976.txt", + key="RFC 7976", + abstract={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. 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.}, + keywords="P-, 3GPP, IMS", + doi="10.17487/RFC7976", + } + +@misc{rfc7977, + author="P. Dunkley and G. Llewellyn and V. Pascual and G. Salgueiro and R. Ravindranath", + title="{The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)}", + howpublished="RFC 7977 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7977", + pages="1--28", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7977.txt", + key="RFC 7977", + abstract={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.}, + keywords="MSRP, WebSocket", + doi="10.17487/RFC7977", + } + +@misc{rfc7978, + author="D. {Eastlake 3rd} and M. Umair and Y. Li", + title="{Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension}", + howpublished="RFC 7978 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7978", + pages="1--25", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7978.txt", + key="RFC 7978", + abstract={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.}, + keywords="tunnel, encapsulation", + doi="10.17487/RFC7978", + } + +@misc{rfc7979, + author="E. {Lear (Ed.)} and R. {Housley (Ed.)}", + title="{Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries}", + howpublished="RFC 7979 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7979", + pages="1--37", + year=2016, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7979.txt", + key="RFC 7979", + abstract={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.}, + doi="10.17487/RFC7979", + } + +@misc{rfc7980, + author="M. Behringer and A. Retana and R. White and G. Huston", + title="{A Framework for Defining Network Complexity}", + howpublished="RFC 7980 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7980", + pages="1--24", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7980.txt", + key="RFC 7980", + abstract={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. 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.}, + keywords="Complicated, Fragile, Self-organization, Trade-off, Technical Debt, Dependency", + doi="10.17487/RFC7980", + } + +@misc{rfc7981, + author="L. Ginsberg and S. Previdi and M. Chen", + title="{IS-IS Extensions for Advertising Router Information}", + howpublished="RFC 7981 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7981", + pages="1--10", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7981.txt", + key="RFC 7981", + abstract={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.}, + doi="10.17487/RFC7981", + } + +@misc{rfc7982, + author="P. Martinsen and T. Reddy and D. Wing and V. Singh", + title="{Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)}", + howpublished="RFC 7982 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7982", + pages="1--10", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7982.txt", + key="RFC 7982", + abstract={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. 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.}, + doi="10.17487/RFC7982", + } + +@misc{rfc7983, + author="M. Petit-Huguenin and G. Salgueiro", + title="{Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 7983 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7983", + pages="1--13", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7983.txt", + key="RFC 7983", + abstract={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. This document updates RFC 5764.}, + keywords="TLS, STUN, TURN, TLS, TURN Channel Numbers, STUN Methods, RFC 5764, SRTP-DTLS, ZRTP", + doi="10.17487/RFC7983", + } + +@misc{rfc7984, + author="O. Johansson and G. Salgueiro and V. Gurbani and D. {Worley (Ed.)}", + title="{Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network}", + howpublished="RFC 7984 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7984", + pages="1--10", + year=2016, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7984.txt", + key="RFC 7984", + abstract={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.}, + keywords="A record, address family preference, AAAA record, DNS, getaddrinfo, Happy Eyeballs, IPv6 address selection, SIP, SRV record, dual-stack, IPv4, IPv6", + doi="10.17487/RFC7984", + } + +@misc{rfc7985, + author="J. Yi and T. Clausen and U. Herberg", + title="{Security Threats to Simplified Multicast Forwarding (SMF)}", + howpublished="RFC 7985 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7985", + pages="1--15", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7985.txt", + key="RFC 7985", + abstract={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. 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).}, + keywords="MANET", + doi="10.17487/RFC7985", + } + +@misc{rfc7986, + author="C. Daboo", + title="{New Properties for iCalendar}", + howpublished="RFC 7986 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7986", + pages="1--23", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7986.txt", + key="RFC 7986", + abstract={This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.}, + keywords="alarms, calendaring, iCalendar", + doi="10.17487/RFC7986", + } + +@misc{rfc7987, + author="L. Ginsberg and P. Wells and B. Decraene and T. Przygienda and H. Gredler", + title="{IS-IS Minimum Remaining Lifetime}", + howpublished="RFC 7987 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7987", + pages="1--9", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7987.txt", + key="RFC 7987", + abstract={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.}, + doi="10.17487/RFC7987", + } + +@misc{rfc7988, + author="E. {Rosen (Ed.)} and K. Subramanian and Z. Zhang", + title="{Ingress Replication Tunnels in Multicast VPN}", + howpublished="RFC 7988 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7988", + pages="1--23", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7988.txt", + key="RFC 7988", + abstract={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 ad ding additional details that are specific to the use of IR tunnels.}, + doi="10.17487/RFC7988", + } + +@misc{rfc7989, + author="P. Jones and G. Salgueiro and C. Pearce and P. Giralt", + title="{End-to-End Session Identification in IP-Based Multimedia Communication Networks}", + howpublished="RFC 7989 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="7989", + pages="1--45", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7989.txt", + key="RFC 7989", + abstract={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). 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. This document obsoletes RFC 7329.}, + keywords="SIP, Session Initiation Protocol, troubleshooting, Session-ID, session identifier, H460.27, remote parameter, UUID", + doi="10.17487/RFC7989", + } + +@misc{rfc7990, + author="H. Flanagan", + title="{RFC Format Framework}", + howpublished="RFC 7990 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7990", + pages="1--16", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7990.txt", + key="RFC 7990", + abstract={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.}, + keywords="Format, xml2rfcv3, v3", + doi="10.17487/RFC7990", + } + +@misc{rfc7991, + author="P. Hoffman", + title="{The ``xml2rfc'' Version 3 Vocabulary}", + howpublished="RFC 7991 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7991", + pages="1--151", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7991.txt", + key="RFC 7991", + abstract={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.}, + keywords="v3, xml2rfcv3, format", + doi="10.17487/RFC7991", + } + +@misc{rfc7992, + author="J. {Hildebrand (Ed.)} and P. Hoffman", + title="{HTML Format for RFCs}", + howpublished="RFC 7992 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7992", + pages="1--43", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7992.txt", + key="RFC 7992", + abstract={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.}, + keywords="html, css, v3, xml2rfcv3, format", + doi="10.17487/RFC7992", + } + +@misc{rfc7993, + author="H. Flanagan", + title="{Cascading Style Sheets (CSS) Requirements for RFCs}", + howpublished="RFC 7993 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7993", + pages="1--14", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7993.txt", + key="RFC 7993", + abstract={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).}, + keywords="v3, xml2rfcv3, format, html", + doi="10.17487/RFC7993", + } + +@misc{rfc7994, + author="H. Flanagan", + title="{Requirements for Plain-Text RFCs}", + howpublished="RFC 7994 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7994", + pages="1--8", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7994.txt", + key="RFC 7994", + abstract={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.}, + keywords="RFC, ASCII, format, plain-text, plain text, xml2rfcv3, v3", + doi="10.17487/RFC7994", + } + +@misc{rfc7995, + author="T. {Hansen (Ed.)} and L. Masinter and M. Hardy", + title="{PDF Format for RFCs}", + howpublished="RFC 7995 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7995", + pages="1--22", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7995.txt", + key="RFC 7995", + abstract={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.}, + keywords="Requests for Comment, xml2rfcv3, v3, format", + doi="10.17487/RFC7995", + } + +@misc{rfc7996, + author="N. Brownlee", + title="{SVG Drawings for RFCs: SVG 1.2 RFC}", + howpublished="RFC 7996 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7996", + pages="1--53", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7996.txt", + key="RFC 7996", + abstract={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.}, + keywords="RFC, v3, xml2rfcv3, format", + doi="10.17487/RFC7996", + } + +@misc{rfc7997, + author="H. {Flanagan (Ed.)}", + title="{The Use of Non-ASCII Characters in RFCs}", + howpublished="RFC 7997 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7997", + pages="1--15", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7997.txt", + key="RFC 7997", + abstract={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. This document updates RFC 7322. Please view this document in PDF form to see the full text.}, + keywords="RFC Series, UTF-8, ASCII, format, non-ASCII, v3, xml2rfcv3", + doi="10.17487/RFC7997", + } + +@misc{rfc7998, + author="P. Hoffman and J. Hildebrand", + title="{``xml2rfc'' Version 3 Preparation Tool Description}", + howpublished="RFC 7998 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7998", + pages="1--18", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7998.txt", + key="RFC 7998", + abstract={This document describes some aspects of the ``prep tool'' that is expected to be created when the new xml2rfc version 3 specification is deployed.}, + keywords="xml2rfcv3, v3, format", + doi="10.17487/RFC7998", + } + +@misc{rfc7999, + author="T. King and C. Dietzel and J. Snijders and G. Doering and G. Hankins", + title="{BLACKHOLE Community}", + howpublished="RFC 7999 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="7999", + pages="1--9", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc7999.txt", + key="RFC 7999", + abstract={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.}, + keywords="well-known, well known, RTBH, Remotely Triggered Blackholing", + doi="10.17487/RFC7999", + } + +@misc{rfc8000, + author="A. Adamson and N. Williams", + title="{Requirements for NFSv4 Multi-Domain Namespace Deployment}", + howpublished="RFC 8000 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8000", + pages="1--17", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8000.txt", + key="RFC 8000", + abstract={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.}, + keywords="multi-domain, multi-domain-capable file system, Federated File System, FedFS", + doi="10.17487/RFC8000", + } + +@misc{rfc8001, + author="F. {Zhang (Ed.)} and O. Gonzalez de {Dios (Ed.)} and C. Margaria and M. Hartley and Z. Ali", + title="{RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information}", + howpublished="RFC 8001 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8001", + pages="1--16", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8001.txt", + key="RFC 8001", + abstract={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).}, + doi="10.17487/RFC8001", + } + +@misc{rfc8002, + author="T. Heer and S. Varjonen", + title="{Host Identity Protocol Certificates}", + howpublished="RFC 8002 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8002", + pages="1--13", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8002.txt", + key="RFC 8002", + abstract={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). 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. This document updates RFC 7401 and obsoletes RFC 6253.}, + keywords="Hip Certificate Extension", + doi="10.17487/RFC8002", + } + +@misc{rfc8003, + author="J. Laganier and L. Eggert", + title="{Host Identity Protocol (HIP) Registration Extension}", + howpublished="RFC 8003 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8003", + pages="1--16", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8003.txt", + key="RFC 8003", + abstract={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.}, + keywords="HIP, Host Identity Protocol, Host Identity Payload, Registration, register", + doi="10.17487/RFC8003", + } + +@misc{rfc8004, + author="J. Laganier and L. Eggert", + title="{Host Identity Protocol (HIP) Rendezvous Extension}", + howpublished="RFC 8004 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8004", + pages="1--14", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8004.txt", + key="RFC 8004", + abstract={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.}, + keywords="HIP, Host Identity Protocol, Host Identity Payload, Rendezvous, HIP nodes, HIP rendezvous server", + doi="10.17487/RFC8004", + } + +@misc{rfc8005, + author="J. Laganier", + title="{Host Identity Protocol (HIP) Domain Name System (DNS) Extension}", + howpublished="RFC 8005 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8005", + pages="1--18", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8005.txt", + key="RFC 8005", + abstract={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.}, + keywords="HIP, Host Identity Protocol, Host Identity Payload, DNS, Domain Name System", + doi="10.17487/RFC8005", + } + +@misc{rfc8006, + author="B. Niven-Jenkins and R. Murray and M. Caulfield and K. Ma", + title="{Content Delivery Network Interconnection (CDNI) Metadata}", + howpublished="RFC 8006 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8006", + pages="1--66", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8006.txt", + key="RFC 8006", + abstract={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.}, + keywords="CDN, cascaded CDN, cascading CDNs, content acquisition, content delegation, request delegation, acquisition protocol, delivery restriction, delivery policy, policy enforcement, delivery protocol, content expiration, geo-fencing, geofencing, geo fencing, geo-blocking, geoblocking, geo blocking, footprint, cache control", + doi="10.17487/RFC8006", + } + +@misc{rfc8007, + author="R. Murray and B. Niven-Jenkins", + title="{Content Delivery Network Interconnection (CDNI) Control Interface / Triggers}", + howpublished="RFC 8007 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8007", + pages="1--49", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8007.txt", + key="RFC 8007", + abstract={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.}, + keywords="CDN, pre-position, invalidate, purge", + doi="10.17487/RFC8007", + } + +@misc{rfc8008, + author="J. Seedorf and J. Peterson and S. Previdi and R. van Brandenburg and K. Ma", + title="{Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics}", + howpublished="RFC 8008 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8008", + pages="1--31", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8008.txt", + key="RFC 8008", + abstract={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 \& 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.}, + keywords="CDNI, CDN Interconnect, Request Routing", + doi="10.17487/RFC8008", + } + +@misc{rfc8009, + author="M. Jenkins and M. Peck and K. Burgin", + title="{AES Encryption with HMAC-SHA2 for Kerberos 5}", + howpublished="RFC 8009 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8009", + pages="1--19", + year=2016, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8009.txt", + key="RFC 8009", + abstract={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.}, + doi="10.17487/RFC8009", + } + +@misc{rfc8010, + author="M. Sweet and I. McDonald", + title="{Internet Printing Protocol/1.1: Encoding and Transport}", + howpublished="RFC 8010 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8010", + pages="1--51", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8010.txt", + key="RFC 8010", + abstract={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).}, + keywords="IPP, Printer, PWG, Printer Working Group", + doi="10.17487/RFC8010", + } + +@misc{rfc8011, + author="M. Sweet and I. McDonald", + title="{Internet Printing Protocol/1.1: Model and Semantics}", + howpublished="RFC 8011 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8011", + pages="1--221", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8011.txt", + key="RFC 8011", + abstract={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. 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. 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). This document obsoletes RFCs 2911, 3381, and 3382.}, + keywords="IPP, Printer, PWG, Printer Working Group", + doi="10.17487/RFC8011", + } + +@misc{rfc8012, + author="N. Akiya and G. Swallow and C. Pignataro and A. Malis and S. Aldrin", + title="{Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)}", + howpublished="RFC 8012 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8012", + pages="1--23", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8012.txt", + key="RFC 8012", + abstract={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. 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.}, + keywords="MPLS, LSP Ping, and Entropy", + doi="10.17487/RFC8012", + } + +@misc{rfc8013, + author="D. Joachimpillai and J. Hadi Salim", + title="{Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)}", + howpublished="RFC 8013 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8013", + pages="1--25", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8013.txt", + key="RFC 8013", + abstract={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.}, + keywords="ForCES, Inter-FE", + doi="10.17487/RFC8013", + } + +@misc{rfc8014, + author="D. Black and J. Hudson and L. Kreeger and M. Lasserre and T. Narten", + title="{An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)}", + howpublished="RFC 8014 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8014", + pages="1--35", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8014.txt", + key="RFC 8014", + abstract={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.}, + doi="10.17487/RFC8014", + } + +@misc{rfc8015, + author="V. Singh and C. Perkins and A. Clark and R. Huang", + title="{RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics}", + howpublished="RFC 8015 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8015", + pages="1--15", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8015.txt", + key="RFC 8015", + abstract={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.}, + keywords="XRBLOCK", + doi="10.17487/RFC8015", + } + +@misc{rfc8016, + author="T. Reddy and D. Wing and P. Patil and P. Martinsen", + title="{Mobility with Traversal Using Relays around NAT (TURN)}", + howpublished="RFC 8016 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8016", + pages="1--13", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8016.txt", + key="RFC 8016", + abstract={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. 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.}, + keywords="IP Address Mobility, VoIP, ICE, STUN, RTP, TUNNEL", + doi="10.17487/RFC8016", + } + +@misc{rfc8017, + author="K. {Moriarty (Ed.)} and B. Kaliski and J. Jonsson and A. Rusch", + title="{PKCS \#1: RSA Cryptography Specifications Version 2.2}", + howpublished="RFC 8017 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8017", + pages="1--78", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8017.txt", + key="RFC 8017", + abstract={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. 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. This document also obsoletes RFC 3447.}, + keywords="RSA public-key cryptosystem, RSA signature scheme, RSA public key, RSA private key, PKCS \#1 v1.5, RSA-OAEP, RSA-PSS, Optimal Asymmetric Encryption Padding, Probabilistic Signature Scheme", + doi="10.17487/RFC8017", + } + +@misc{rfc8018, + author="K. {Moriarty (Ed.)} and B. Kaliski and A. Rusch", + title="{PKCS \#5: Password-Based Cryptography Specification Version 2.1}", + howpublished="RFC 8018 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8018", + pages="1--40", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8018.txt", + key="RFC 8018", + abstract={This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This 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. This document also obsoletes RFC 2898.}, + keywords="password-based encryption, password-based key derivation, salt", + doi="10.17487/RFC8018", + } + +@misc{rfc8019, + author="Y. Nir and V. Smyslov", + title="{Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks}", + howpublished="RFC 8019 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8019", + pages="1--32", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8019.txt", + key="RFC 8019", + abstract={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.}, + keywords="puzzle, dos, ddos, bitcoin", + doi="10.17487/RFC8019", + } + +@misc{rfc8020, + author="S. Bortzmeyer and S. Huque", + title="{NXDOMAIN: There Really Is Nothing Underneath}", + howpublished="RFC 8020 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8020", + pages="1--10", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8020.txt", + key="RFC 8020", + abstract={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. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.}, + doi="10.17487/RFC8020", + } + +@misc{rfc8021, + author="F. Gont and W. Liu and T. Anderson", + title="{Generation of IPv6 Atomic Fragments Considered Harmful}", + howpublished="RFC 8021 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8021", + pages="1--12", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8021.txt", + key="RFC 8021", + abstract={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).}, + keywords="attack, DoS, Extension Headers", + doi="10.17487/RFC8021", + } + +@misc{rfc8022, + author="L. Lhotka and A. Lindem", + title="{A YANG Data Model for Routing Management}", + howpublished="RFC 8022 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8022", + pages="1--64", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8349", +url="https://www.rfc-editor.org/rfc/rfc8022.txt", + key="RFC 8022", + abstract={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.}, + keywords="configuration, IPv6 router advertisements, NETCONF, RESTCONF", + doi="10.17487/RFC8022", + } + +@misc{rfc8023, + author="M. Thomas and A. Mankin and L. Zhang", + title="{Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions}", + howpublished="RFC 8023 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8023", + pages="1--17", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8023.txt", + key="RFC 8023", + abstract={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.}, + doi="10.17487/RFC8023", + } + +@misc{rfc8024, + author="Y. {Jiang (Ed.)} and Y. Luo and E. {Mallette (Ed.)} and Y. Shen and W. Cheng", + title="{Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS}", + howpublished="RFC 8024 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8024", + pages="1--16", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8024.txt", + key="RFC 8024", + abstract={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.}, + keywords="PON Protection", + doi="10.17487/RFC8024", + } + +@misc{rfc8025, + author="P. {Thubert (Ed.)} and R. Cragie", + title="{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch}", + howpublished="RFC 8025 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8025", + pages="1--8", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8025.txt", + key="RFC 8025", + abstract={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.}, + keywords="LNN, IOT", + doi="10.17487/RFC8025", + } + +@misc{rfc8026, + author="M. Boucadair and I. Farrer", + title="{Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism}", + howpublished="RFC 8026 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8026", + pages="1--11", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8026.txt", + key="RFC 8026", + abstract={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.}, + keywords="Provisioning, Softwire, IPv4 over IPv6, IPv4 service continuity, IPv4 address depletion, MAP, MAP-T, MAP-E, DS-Lite, Lightweight 4 over 6", + doi="10.17487/RFC8026", + } + +@misc{rfc8027, + author="W. Hardaker and O. Gudmundsson and S. Krishnaswamy", + title="{DNSSEC Roadblock Avoidance}", + howpublished="RFC 8027 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8027", + pages="1--19", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8027.txt", + key="RFC 8027", + abstract={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.}, + keywords="DNSSEC, Network Problems, DNS", + doi="10.17487/RFC8027", + } + +@misc{rfc8028, + author="F. Baker and B. Carpenter", + title="{First-Hop Router Selection by Hosts in a Multi-Prefix Network}", + howpublished="RFC 8028 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8028", + pages="1--13", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8028.txt", + key="RFC 8028", + abstract={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 transmi ssion. It updates RFC 4861.}, + doi="10.17487/RFC8028", + } + +@misc{rfc8029, + author="K. Kompella and G. Swallow and C. {Pignataro (Ed.)} and N. Kumar and S. Aldrin and M. Chen", + title="{Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures}", + howpublished="RFC 8029 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8029", + pages="1--78", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8029.txt", + key="RFC 8029", + abstract={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. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.}, + keywords="MPLS echo request, MPLS echo reply", + doi="10.17487/RFC8029", + } + +@misc{rfc8030, + author="M. Thomson and E. Damaggio and B. {Raymor (Ed.)}", + title="{Generic Event Delivery Using HTTP Push}", + howpublished="RFC 8030 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8030", + pages="1--31", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8030.txt", + key="RFC 8030", + abstract={This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.}, + keywords="HTTP, HTTP2, Push, WebPush", + doi="10.17487/RFC8030", + } + +@misc{rfc8031, + author="Y. Nir and S. Josefsson", + title="{Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement}", + howpublished="RFC 8031 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8031", + pages="1--8", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8031.txt", + key="RFC 8031", + abstract={This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).}, + keywords="Curve25519, Curve448, Goldilocks, Diffie Hellman", + doi="10.17487/RFC8031", + } + +@misc{rfc8032, + author="S. Josefsson and I. Liusvaara", + title="{Edwards-Curve Digital Signature Algorithm (EdDSA)}", + howpublished="RFC 8032 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8032", + pages="1--60", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8032.txt", + key="RFC 8032", + abstract={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.}, + keywords="signature, digital signature, EdDSA", + doi="10.17487/RFC8032", + } + +@misc{rfc8033, + author="R. Pan and P. Natarajan and F. Baker and G. White", + title="{Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem}", + howpublished="RFC 8033 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8033", + pages="1--30", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8033.txt", + key="RFC 8033", + abstract={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. 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.}, + keywords="active queue management, AQM", + doi="10.17487/RFC8033", + } + +@misc{rfc8034, + author="G. White and R. Pan", + title="{Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems}", + howpublished="RFC 8034 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8034", + pages="1--17", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8034.txt", + key="RFC 8034", + abstract={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.}, + keywords="latency, access network, bufferbloat", + doi="10.17487/RFC8034", + } + +@misc{rfc8035, + author="C. Holmberg", + title="{Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing}", + howpublished="RFC 8035 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8035", + pages="1--7", + year=2016, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8035.txt", + key="RFC 8035", + abstract={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.}, + keywords="RTP, RTCP, multiplex, rtcp-mux, SDP, offer, answer", + doi="10.17487/RFC8035", + } + +@misc{rfc8036, + author="N. {Cam-Winget (Ed.)} and J. Hui and D. Popa", + title="{Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks}", + howpublished="RFC 8036 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8036", + pages="1--24", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8036.txt", + key="RFC 8036", + abstract={This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.}, + keywords="constrained environment, smart meter, utilities, smartgrid, secure smartgrid, connected energy", + doi="10.17487/RFC8036", + } + +@misc{rfc8037, + author="I. Liusvaara", + title="{CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)}", + howpublished="RFC 8037 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8037", + pages="1--14", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8037.txt", + key="RFC 8037", + abstract={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).}, + keywords="Ed25519, Ed448, X25519, X448", + doi="10.17487/RFC8037", + } + +@misc{rfc8038, + author="P. {Aitken (Ed.)} and B. Claise and S. B S and C. McDowall and J. Schoenwaelder", + title="{Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol}", + howpublished="RFC 8038 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8038", + pages="1--85", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8038.txt", + key="RFC 8038", + abstract={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. 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.}, + keywords="IPFIX, MIB, SNMP", + doi="10.17487/RFC8038", + } + +@misc{rfc8039, + author="A. Shpiner and R. Tse and C. Schelp and T. Mizrahi", + title="{Multipath Time Synchronization}", + howpublished="RFC 8039 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8039", + pages="1--17", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8039.txt", + key="RFC 8039", + abstract={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.}, + keywords="NTP, PTP, IEEE 1588, multiple paths", + doi="10.17487/RFC8039", + } + +@misc{rfc8040, + author="A. Bierman and M. Bjorklund and K. Watsen", + title="{RESTCONF Protocol}", + howpublished="RFC 8040 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8040", + pages="1--137", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8040.txt", + key="RFC 8040", + abstract={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).}, + keywords="YANG, NETCONF, REST, HTTP", + doi="10.17487/RFC8040", + } + +@misc{rfc8041, + author="O. Bonaventure and C. Paasch and G. Detal", + title="{Use Cases and Operational Experience with Multipath TCP}", + howpublished="RFC 8041 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8041", + pages="1--30", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8041.txt", + key="RFC 8041", + abstract={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.}, + keywords="TCP, MPTCP, Middlebox, Congestion Control, Path Manager, Scheduler, Proxy, Load-Balancer, Datacenter, Cellular/WiFi Offload, Hybrid Access Networks", + doi="10.17487/RFC8041", + } + +@misc{rfc8042, + author="Z. Zhang and L. Wang and A. Lindem", + title="{OSPF Two-Part Metric}", + howpublished="RFC 8042 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8042", + pages="1--9", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8042.txt", + key="RFC 8042", + abstract={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.}, + keywords="OSPF, Broadcast, Interface, SPF metrics, Radio Networks", + doi="10.17487/RFC8042", + } + +@misc{rfc8043, + author="B. Sarikaya and M. Boucadair", + title="{Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space}", + howpublished="RFC 8043 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8043", + pages="1--16", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8043.txt", + key="RFC 8043", + abstract={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. 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.}, + keywords="Neighbor Discovery, Duplicate Address Detection, ND Relay Agent", + doi="10.17487/RFC8043", + } + +@misc{rfc8044, + author="A. DeKok", + title="{Data Types in RADIUS}", + howpublished="RFC 8044 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8044", + pages="1--35", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8044.txt", + key="RFC 8044", + abstract={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.}, + doi="10.17487/RFC8044", + } + +@misc{rfc8045, + author="D. Cheng and J. Korhonen and M. Boucadair and S. Sivakumar", + title="{RADIUS Extensions for IP Port Configuration and Reporting}", + howpublished="RFC 8045 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8045", + pages="1--43", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8045.txt", + key="RFC 8045", + abstract={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.}, + keywords="address sharing, address continuity, CGN, NAT, IP assignment, port assignment, port control, port accounting, port set, port range, IP/Port Limit, Provider Wi-Fi, Port forwarding, Internal port, External port, Port mapping", + doi="10.17487/RFC8045", + } + +@misc{rfc8046, + author="T. {Henderson (Ed.)} and C. Vogt and J. Arkko", + title="{Host Mobility with the Host Identity Protocol}", + howpublished="RFC 8046 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8046", + pages="1--37", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8046.txt", + key="RFC 8046", + abstract={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.}, + keywords="hip, multihoming extensions, mobility extensions, locator", + doi="10.17487/RFC8046", + } + +@misc{rfc8047, + author="T. {Henderson (Ed.)} and C. Vogt and J. Arkko", + title="{Host Multihoming with the Host Identity Protocol}", + howpublished="RFC 8047 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8047", + pages="1--22", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8047.txt", + key="RFC 8047", + abstract={This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.}, + keywords="hip, multihoming extensions, mobility extensions, locator", + doi="10.17487/RFC8047", + } + +@misc{rfc8048, + author="P. Saint-Andre", + title="{Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence}", + howpublished="RFC 8048 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8048", + pages="1--34", + year=2016, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8048.txt", + key="RFC 8048", + abstract={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.}, + keywords="Extensible Messaging and Presence Protocol, XMPP, Jabber, Session Initiation Protocol, SIP, SIMPLE, presence, availability", + doi="10.17487/RFC8048", + } + +@misc{rfc8049, + author="S. Litkowski and L. Tomotaki and K. Ogaki", + title="{YANG Data Model for L3VPN Service Delivery}", + howpublished="RFC 8049 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8049", + pages="1--157", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Obsoleted by RFC 8299", +url="https://www.rfc-editor.org/rfc/rfc8049.txt", + key="RFC 8049", + abstract={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.}, + keywords="YANG, l3sm, l3vpn, service model", + doi="10.17487/RFC8049", + } + +@misc{rfc8050, + author="C. Petrie and T. King", + title="{Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions}", + howpublished="RFC 8050 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8050", + pages="1--6", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8050.txt", + key="RFC 8050", + abstract={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.}, + doi="10.17487/RFC8050", + } + +@misc{rfc8051, + author="X. {Zhang (Ed.)} and I. {Minei (Ed.)}", + title="{Applicability of a Stateful Path Computation Element (PCE)}", + howpublished="RFC 8051 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8051", + pages="1--24", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8051.txt", + key="RFC 8051", + abstract={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.}, + keywords="Stateful PCE, Applicability", + doi="10.17487/RFC8051", + } + +@misc{rfc8052, + author="B. Weis and M. Seewald and H. Falk", + title="{Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services}", + howpublished="RFC 8052 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8052", + pages="1--25", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8052.txt", + key="RFC 8052", + abstract={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.}, + doi="10.17487/RFC8052", + } + +@misc{rfc8053, + author="Y. Oiwa and H. Watanabe and H. Takagi and K. Maeda and T. Hayashi and Y. Ioku", + title="{HTTP Authentication Extensions for Interactive Clients}", + howpublished="RFC 8053 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8053", + pages="1--28", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8053.txt", + key="RFC 8053", + abstract={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.}, + doi="10.17487/RFC8053", + } + +@misc{rfc8054, + author="K. Murchison and J. Elie", + title="{Network News Transfer Protocol (NNTP) Extension for Compression}", + howpublished="RFC 8054 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8054", + pages="1--23", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8054.txt", + key="RFC 8054", + abstract={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.}, + keywords="NNTP, Usenet, NetNews, COMPRESS, DEFLATE, compression", + doi="10.17487/RFC8054", + } + +@misc{rfc8055, + author="C. Holmberg and Y. Jiang", + title="{Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm}", + howpublished="RFC 8055 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8055", + pages="1--13", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8055.txt", + key="RFC 8055", + abstract={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.}, + keywords="SIP, Via, transit, realm", + doi="10.17487/RFC8055", + } + +@misc{rfc8056, + author="J. Gould", + title="{Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping}", + howpublished="RFC 8056 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8056", + pages="1--11", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8056.txt", + key="RFC 8056", + abstract={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.}, + doi="10.17487/RFC8056", + } + +@misc{rfc8057, + author="B. Stark and D. Sinicrope and W. Lupton", + title="{Uniform Resource Name (URN) Namespaces for Broadband Forum}", + howpublished="RFC 8057 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8057", + pages="1--11", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8057.txt", + key="RFC 8057", + abstract={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.}, + keywords="URN, Broadband Forum, BBF", + doi="10.17487/RFC8057", + } + +@misc{rfc8058, + author="J. Levine and T. Herkula", + title="{Signaling One-Click Functionality for List Email Headers}", + howpublished="RFC 8058 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8058", + pages="1--9", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8058.txt", + key="RFC 8058", + abstract={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.}, + keywords="email, mailing list", + doi="10.17487/RFC8058", + } + +@misc{rfc8059, + author="J. Arango and S. Venaas and I. Kouvelas and D. Farinacci", + title="{PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments}", + howpublished="RFC 8059 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8059", + pages="1--9", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8059.txt", + key="RFC 8059", + abstract={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).}, + doi="10.17487/RFC8059", + } + +@misc{rfc8060, + author="D. Farinacci and D. Meyer and J. Snijders", + title="{LISP Canonical Address Format (LCAF)}", + howpublished="RFC 8060 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8060", + pages="1--36", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8060.txt", + key="RFC 8060", + abstract={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.}, + keywords="Locator/ID Separation Protocol", + doi="10.17487/RFC8060", + } + +@misc{rfc8061, + author="D. Farinacci and B. Weis", + title="{Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality}", + howpublished="RFC 8061 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8061", + pages="1--18", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8061.txt", + key="RFC 8061", + abstract={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.}, + keywords="lcaf", + doi="10.17487/RFC8061", + } + +@misc{rfc8062, + author="L. Zhu and P. Leach and S. Hartman and S. {Emery (Ed.)}", + title="{Anonymity Support for Kerberos}", + howpublished="RFC 8062 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8062", + pages="1--18", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8062.txt", + key="RFC 8062", + abstract={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.}, + doi="10.17487/RFC8062", + } + +@misc{rfc8063, + author="H.W. Ribbers and M.W. Groeneweg and R. Gieben and A.L.J. Verschuren", + title="{Key Relay Mapping for the Extensible Provisioning Protocol}", + howpublished="RFC 8063 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8063", + pages="1--16", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8063.txt", + key="RFC 8063", + abstract={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. This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.}, + keywords="Extensible Provisioning Protocol", + doi="10.17487/RFC8063", + } + +@misc{rfc8064, + author="F. Gont and A. Cooper and D. Thaler and W. Liu", + title="{Recommendation on Stable IPv6 Interface Identifiers}", + howpublished="RFC 8064 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8064", + pages="1--9", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8064.txt", + key="RFC 8064", + abstract={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.}, + doi="10.17487/RFC8064", + } + +@misc{rfc8065, + author="D. Thaler", + title="{Privacy Considerations for IPv6 Adaptation-Layer Mechanisms}", + howpublished="RFC 8065 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8065", + pages="1--10", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8065.txt", + key="RFC 8065", + abstract={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.}, + doi="10.17487/RFC8065", + } + +@misc{rfc8066, + author="S. Chakrabarti and G. Montenegro and R. Droms and J. Woodyatt", + title="{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines}", + howpublished="RFC 8066 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8066", + pages="1--9", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8066.txt", + key="RFC 8066", + abstract={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.}, + doi="10.17487/RFC8066", + } + +@misc{rfc8067, + author="B. Leiba", + title="{Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level}", + howpublished="RFC 8067 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8067", + pages="1--3", + year=2017, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8067.txt", + key="RFC 8067", + abstract={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.}, + keywords="downref, maturity, last call", + doi="10.17487/RFC8067", + } + +@misc{rfc8068, + author="R. Ravindranath and P. Ravindran and P. Kyzivat", + title="{Session Initiation Protocol (SIP) Recording Call Flows}", + howpublished="RFC 8068 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8068", + pages="1--34", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8068.txt", + key="RFC 8068", + abstract={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).}, + keywords="sipreq", + doi="10.17487/RFC8068", + } + +@misc{rfc8069, + author="A. Thomas", + title="{URN Namespace for IEEE}", + howpublished="RFC 8069 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8069", + pages="1--6", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8069.txt", + key="RFC 8069", + abstract={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.}, + doi="10.17487/RFC8069", + } + +@misc{rfc8070, + author="M. {Short (Ed.)} and S. Moore and P. Miller", + title="{Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension}", + howpublished="RFC 8070 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8070", + pages="1--9", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8070.txt", + key="RFC 8070", + abstract={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.}, + doi="10.17487/RFC8070", + } + +@misc{rfc8071, + author="K. Watsen", + title="{NETCONF Call Home and RESTCONF Call Home}", + howpublished="RFC 8071 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8071", + pages="1--13", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8071.txt", + key="RFC 8071", + abstract={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.}, + keywords="call-home", + doi="10.17487/RFC8071", + } + +@misc{rfc8072, + author="A. Bierman and M. Bjorklund and K. Watsen", + title="{YANG Patch Media Type}", + howpublished="RFC 8072 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8072", + pages="1--39", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8072.txt", + key="RFC 8072", + abstract={This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.}, + keywords="RESTCONF", + doi="10.17487/RFC8072", + } + +@misc{rfc8073, + author="K. Moriarty and M. Ford", + title="{Coordinating Attack Response at Internet Scale (CARIS) Workshop Report}", + howpublished="RFC 8073 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8073", + pages="1--16", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8073.txt", + key="RFC 8073", + abstract={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. 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.}, + doi="10.17487/RFC8073", + } + +@misc{rfc8074, + author="J. Bi and G. Yao and J. Halpern and E. {Levy-Abegnoli (Ed.)}", + title="{Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario}", + howpublished="RFC 8074 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8074", + pages="1--12", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8074.txt", + key="RFC 8074", + abstract={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.}, + keywords="SAVI-DHCP, FCFS SAVI, SEND SAVI", + doi="10.17487/RFC8074", + } + +@misc{rfc8075, + author="A. Castellani and S. Loreto and A. Rahman and T. Fossati and E. Dijk", + title="{Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)}", + howpublished="RFC 8075 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8075", + pages="1--40", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8075.txt", + key="RFC 8075", + abstract={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.}, + keywords="CoAP, HTTP-CoAP mapping, HTTP-CoAP translation, proxy implementation", + doi="10.17487/RFC8075", + } + +@misc{rfc8076, + author="A. Knauf and T. {Schmidt (Ed.)} and G. Hege and M. Waehlisch", + title="{A Usage for Shared Resources in RELOAD (ShaRe)}", + howpublished="RFC 8076 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8076", + pages="1--22", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8076.txt", + key="RFC 8076", + abstract={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.}, + keywords="P2PSIP, SIP, Conferencing, Voice over IP, Peer-to-Peer, Access Control, Group Management, Rendezvous", + doi="10.17487/RFC8076", + } + +@misc{rfc8077, + author="L. {Martini (Ed.)} and G. {Heron (Ed.)}", + title="{Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)}", + howpublished="RFC 8077 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8077", + pages="1--35", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8077.txt", + key="RFC 8077", + abstract={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. This document is a rewrite of RFC 4447 for publication as an Internet Standard.}, + doi="10.17487/RFC8077", + } + +@misc{rfc8078, + author="O. Gudmundsson and P. Wouters", + title="{Managing DS Records from the Parent via CDS/CDNSKEY}", + howpublished="RFC 8078 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8078", + pages="1--10", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8078.txt", + key="RFC 8078", + abstract={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. 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. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records). 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) r ollover. 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.}, + keywords="dnssec, trust maintenance", + doi="10.17487/RFC8078", + } + +@misc{rfc8079, + author="L. Miniero and S. Garcia Murillo and V. Pascual", + title="{Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)}", + howpublished="RFC 8079 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8079", + pages="1--16", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8079.txt", + key="RFC 8079", + abstract={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. 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.}, + doi="10.17487/RFC8079", + } + +@misc{rfc8080, + author="O. Sury and R. Edmonds", + title="{Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC}", + howpublished="RFC 8080 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8080", + pages="1--7", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8080.txt", + key="RFC 8080", + abstract={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.}, + keywords="DNSSEC, EdDSA, ed25519, ed448", + doi="10.17487/RFC8080", + } + +@misc{rfc8081, + author="C. Lilley", + title="{The ``font'' Top-Level Media Type}", + howpublished="RFC 8081 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8081", + pages="1--18", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8081.txt", + key="RFC 8081", + abstract={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.}, + keywords="Internet Media Types, MIME", + doi="10.17487/RFC8081", + } + +@misc{rfc8082, + author="S. Wenger and J. Lennox and B. Burman and M. Westerlund", + title="{Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs}", + howpublished="RFC 8082 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8082", + pages="1--11", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8082.txt", + key="RFC 8082", + abstract={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.}, + keywords="Layered Codec, Full Intra Request, FIR, Decoder Refresh Point", + doi="10.17487/RFC8082", + } + +@misc{rfc8083, + author="C. Perkins and V. Singh", + title="{Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions}", + howpublished="RFC 8083 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8083", + pages="1--25", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8083.txt", + key="RFC 8083", + abstract={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. 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-li ved 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.}, + doi="10.17487/RFC8083", + } + +@misc{rfc8084, + author="G. Fairhurst", + title="{Network Transport Circuit Breakers}", + howpublished="RFC 8084 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8084", + pages="1--24", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8084.txt", + key="RFC 8084", + abstract={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.}, + keywords="Congestion control, CC, UDP, Tunnel, Encapsulation, Transport Protocol, Congestion Control", + doi="10.17487/RFC8084", + } + +@misc{rfc8085, + author="L. Eggert and G. Fairhurst and G. Shepherd", + title="{UDP Usage Guidelines}", + howpublished="RFC 8085 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8085", + pages="1--55", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8085.txt", + key="RFC 8085", + abstract={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. 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. 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. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.}, + keywords="UDP, guidelines", + doi="10.17487/RFC8085", + } + +@misc{rfc8086, + author="L. {Yong (Ed.)} and E. Crabbe and X. Xu and T. Herbert", + title="{GRE-in-UDP Encapsulation}", + howpublished="RFC 8086 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8086", + pages="1--27", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8086.txt", + key="RFC 8086", + abstract={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.}, + doi="10.17487/RFC8086", + } + +@misc{rfc8087, + author="G. Fairhurst and M. Welzl", + title="{The Benefits of Using Explicit Congestion Notification (ECN)}", + howpublished="RFC 8087 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8087", + pages="1--19", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8087.txt", + key="RFC 8087", + abstract={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.}, + keywords="ecn, aqm, sctp, tcp", + doi="10.17487/RFC8087", + } + +@misc{rfc8088, + author="M. Westerlund", + title="{How to Write an RTP Payload Format}", + howpublished="RFC 8088 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8088", + pages="1--65", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8088.txt", + key="RFC 8088", + abstract={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.}, + keywords="RTP, Payload format, Process", + doi="10.17487/RFC8088", + } + +@misc{rfc8089, + author="M. Kerwin", + title="{The ``file'' URI Scheme}", + howpublished="RFC 8089 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8089", + pages="1--19", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8089.txt", + key="RFC 8089", + abstract={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. 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.}, + keywords="uniform resource identifier, URL", + doi="10.17487/RFC8089", + } + +@misc{rfc8090, + author="R. Housley", + title="{Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG)}", + howpublished="RFC 8090 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8090", + pages="1--7", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8090.txt", + key="RFC 8090", + abstract={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.}, + doi="10.17487/RFC8090", + } + +@misc{rfc8091, + author="E. Wilde", + title="{A Media Type Structured Syntax Suffix for JSON Text Sequences}", + howpublished="RFC 8091 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8091", + pages="1--5", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8091.txt", + key="RFC 8091", + abstract={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.}, + doi="10.17487/RFC8091", + } + +@misc{rfc8092, + author="J. {Heitz (Ed.)} and J. {Snijders (Ed.)} and K. Patel and I. Bagdonas and N. Hilliard", + title="{BGP Large Communities Attribute}", + howpublished="RFC 8092 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8092", + pages="1--8", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8092.txt", + key="RFC 8092", + abstract={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.}, + keywords="BGP, large, communities, four-octet", + doi="10.17487/RFC8092", + } + +@misc{rfc8093, + author="J. Snijders", + title="{Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243}", + howpublished="RFC 8093 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8093", + pages="1--3", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8093.txt", + key="RFC 8093", + abstract={This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as ``Deprecated''.}, + doi="10.17487/RFC8093", + } + +@misc{rfc8094, + author="T. Reddy and D. Wing and P. Patil", + title="{DNS over Datagram Transport Layer Security (DTLS)}", + howpublished="RFC 8094 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8094", + pages="1--13", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8094.txt", + key="RFC 8094", + abstract={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. 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.}, + doi="10.17487/RFC8094", + } + +@misc{rfc8095, + author="G. {Fairhurst (Ed.)} and B. {Trammell (Ed.)} and M. {Kuehlewind (Ed.)}", + title="{Services Provided by IETF Transport Protocols and Congestion Control Mechanisms}", + howpublished="RFC 8095 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8095", + pages="1--54", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8095.txt", + key="RFC 8095", + abstract={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.}, + keywords="Transmission Control Protocol (TCP), Multipath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), UDP-Lite, Datagram Congestion Control Protocol (DCCP), Internet Control Message Protocol (ICMP), 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), Hypertext Transport Protocol (HTTP), TAPS", + doi="10.17487/RFC8095", + } + +@misc{rfc8096, + author="B. Fenner", + title="{The IPv6-Specific MIB Modules Are Obsolete}", + howpublished="RFC 8096 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8096", + pages="1--65", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8096.txt", + key="RFC 8096", + abstract={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.}, + doi="10.17487/RFC8096", + } + +@misc{rfc8097, + author="P. Mohapatra and K. Patel and J. Scudder and D. Ward and R. Bush", + title="{BGP Prefix Origin Validation State Extended Community}", + howpublished="RFC 8097 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8097", + pages="1--6", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8097.txt", + key="RFC 8097", + abstract={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.}, + doi="10.17487/RFC8097", + } + +@misc{rfc8098, + author="T. {Hansen (Ed.)} and A. {Melnikov (Ed.)}", + title="{Message Disposition Notification}", + howpublished="RFC 8098 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8098", + pages="1--37", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8098.txt", + key="RFC 8098", + abstract={This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message 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. 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. 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).}, + keywords="delivery notification, mdn", + doi="10.17487/RFC8098", + } + +@misc{rfc8099, + author="H. Chen and R. Li and A. Retana and Y. Yang and Z. Liu", + title="{OSPF Topology-Transparent Zone}", + howpublished="RFC 8099 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8099", + pages="1--27", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8099.txt", + key="RFC 8099", + abstract={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.}, + keywords="IGP, OSPF, TTZ", + doi="10.17487/RFC8099", + } + +@misc{rfc8100, + author="R. {Geib (Ed.)} and D. Black", + title="{Diffserv-Interconnection Classes and Practice}", + howpublished="RFC 8100 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8100", + pages="1--21", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8100.txt", + key="RFC 8100", + abstract={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.}, + keywords="Diffserv, Interconnection, PHB, Treatment Aggregate, MPLS Short Pipe", + doi="10.17487/RFC8100", + } + +@misc{rfc8101, + author="C. Holmberg and J. Axell", + title="{IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service}", + howpublished="RFC 8101 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8101", + pages="1--6", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8101.txt", + key="RFC 8101", + abstract={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.}, + keywords="Resource-Priority, namespace, Resource-priorith, 3GPP, IMS, MCPTT", + doi="10.17487/RFC8101", + } + +@misc{rfc8102, + author="P. {Sarkar (Ed.)} and S. Hegde and C. Bowers and H. Gredler and S. Litkowski", + title="{Remote-LFA Node Protection and Manageability}", + howpublished="RFC 8102 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8102", + pages="1--22", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8102.txt", + key="RFC 8102", + abstract={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. 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.}, + keywords="LFA, Remote-LFA, IGP, Node Protection", + doi="10.17487/RFC8102", + } + +@misc{rfc8103, + author="R. Housley", + title="{Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 8103 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8103", + pages="1--9", + year=2017, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8103.txt", + key="RFC 8103", + abstract={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.}, + doi="10.17487/RFC8103", + } + +@misc{rfc8104, + author="Y. Shen and R. Aggarwal and W. Henderickx and Y. Jiang", + title="{Pseudowire (PW) Endpoint Fast Failure Protection}", + howpublished="RFC 8104 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8104", + pages="1--43", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8104.txt", + key="RFC 8104", + abstract={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.}, + keywords="pseudowire, PW, protection, local repair, fast reroute", + doi="10.17487/RFC8104", + } + +@misc{rfc8105, + author="P. Mariager and J. {Petersen (Ed.)} and Z. Shelby and M. Van de Logt and D. Barthel", + title="{Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)}", + howpublished="RFC 8105 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8105", + pages="1--22", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8105.txt", + key="RFC 8105", + abstract={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. 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. 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. This document describes how IPv6 is transported over DECT ULE us ing IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.}, + keywords="6LoWPAN, ETSI, IoT, and Internet of Things", + doi="10.17487/RFC8105", + } + +@misc{rfc8106, + author="J. Jeong and S. Park and L. Beloeil and S. Madanapalli", + title="{IPv6 Router Advertisement Options for DNS Configuration}", + howpublished="RFC 8106 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8106", + pages="1--19", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8106.txt", + key="RFC 8106", + abstract={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. 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.}, + keywords="DNS Service, DNS Option, Recursive DNS Server Address, DNS Search List, Stateless Autoconfiguration", + doi="10.17487/RFC8106", + } + +@misc{rfc8107, + author="J. Wold", + title="{Advertising Digital Identifier (Ad-ID) URN Namespace Definition}", + howpublished="RFC 8107 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8107", + pages="1--7", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8107.txt", + key="RFC 8107", + abstract={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.}, + doi="10.17487/RFC8107", + } + +@misc{rfc8108, + author="J. Lennox and M. Westerlund and Q. Wu and C. Perkins", + title="{Sending Multiple RTP Streams in a Single RTP Session}", + howpublished="RFC 8108 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8108", + pages="1--29", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8108.txt", + key="RFC 8108", + abstract={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.}, + doi="10.17487/RFC8108", + } + +@misc{rfc8109, + author="P. Koch and M. Larson and P. Hoffman", + title="{Initializing a DNS Resolver with Priming Queries}", + howpublished="RFC 8109 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8109", + pages="1--7", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8109.txt", + key="RFC 8109", + abstract={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.}, + doi="10.17487/RFC8109", + } + +@misc{rfc8110, + author="D. {Harkins (Ed.)} and W. {Kumari (Ed.)}", + title="{Opportunistic Wireless Encryption}", + howpublished="RFC 8110 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8110", + pages="1--12", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8110.txt", + key="RFC 8110", + abstract={This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.}, + keywords="opportunistic encryption wireless", + doi="10.17487/RFC8110", + } + +@misc{rfc8111, + author="V. Fuller and D. Lewis and V. Ermagan and A. Jain and A. Smirnov", + title="{Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)}", + howpublished="RFC 8111 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8111", + pages="1--44", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8111.txt", + key="RFC 8111", + abstract={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.}, + keywords="LISP, DDT, EID, Locator, Mapping System, Map-Server, Map-Referral, Referral", + doi="10.17487/RFC8111", + } + +@misc{rfc8112, + author="D. Farinacci and A. Jain and I. Kouvelas and D. Lewis", + title="{Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)}", + howpublished="RFC 8112 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8112", + pages="1--11", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8112.txt", + key="RFC 8112", + abstract={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.}, + doi="10.17487/RFC8112", + } + +@misc{rfc8113, + author="M. Boucadair and C. Jacquenet", + title="{Locator/ID Separation Protocol (LISP): Shared Extension Message \& IANA Registry for Packet Type Allocations}", + howpublished="RFC 8113 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8113", + pages="1--6", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8113.txt", + key="RFC 8113", + abstract={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.}, + keywords="Shared Experiment Code, LISP codepoints, Experiment Identifier, Experiment ID, LISP Experimental Registry, LISP Extension, Extending LISP", + doi="10.17487/RFC8113", + } + +@misc{rfc8114, + author="M. Boucadair and C. Qin and C. Jacquenet and Y. Lee and Q. Wang", + title="{Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network}", + howpublished="RFC 8114 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8114", + pages="1--23", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8114.txt", + key="RFC 8114", + abstract={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).}, + keywords="Multicast, DS-Lite, IPv4-IPv6 Interconnection, PREFIX64, SSM, ASM, IPv4 service continuity, Multicast service continuity, IPv6-only, IPv6-only multicast, PIM, MLD, IGMP, A+P, MAP, MAP-E, address-sharing, CGN, NAT64, IPv4 over IPv6, IPv6 Address Synthesis, Any-Source Multicast, Source-Specific Multicast", + doi="10.17487/RFC8114", + } + +@misc{rfc8115, + author="M. Boucadair and J. Qin and T. Tsou and X. Deng", + title="{DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes}", + howpublished="RFC 8115 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8115", + pages="1--9", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8115.txt", + key="RFC 8115", + abstract={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.}, + keywords="PREFIX64, SSM, ASM, Prefix Discovery, IPv4-Converted IPv6 Addresses, IPv4 service continuity, IPv6 Address Synthesis, Any-Source Multicast, Source-Specific Multicast, PIM, IPv4-IPv6 interconnection, IPv4 over IPv6, A+P, MAP, MAP-E, address-sharing, CGN, NAT64", + doi="10.17487/RFC8115", + } + +@misc{rfc8116, + author="T. Clausen and U. Herberg and J. Yi", + title="{Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)}", + howpublished="RFC 8116 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8116", + pages="1--26", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8116.txt", + key="RFC 8116", + abstract={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.}, + keywords="MANET", + doi="10.17487/RFC8116", + } + +@misc{rfc8117, + author="C. Huitema and D. Thaler and R. Winter", + title="{Current Hostname Practice Considered Harmful}", + howpublished="RFC 8117 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8117", + pages="1--12", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8117.txt", + key="RFC 8117", + abstract={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. 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.}, + doi="10.17487/RFC8117", + } + +@misc{rfc8118, + author="M. Hardy and L. Masinter and D. Markovic and D. Johnson and M. Bailey", + title="{The application/pdf Media Type}", + howpublished="RFC 8118 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8118", + pages="1--12", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8118.txt", + key="RFC 8118", + abstract={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.}, + keywords="Portable Document Format, MIME type", + doi="10.17487/RFC8118", + } + +@misc{rfc8119, + author="M. Mohali and M. Barnes", + title="{SIP ``cause'' URI Parameter for Service Number Translation}", + howpublished="RFC 8119 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8119", + pages="1--12", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8119.txt", + key="RFC 8119", + abstract={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.}, + keywords="Cause", + doi="10.17487/RFC8119", + } + +@misc{rfc8120, + author="Y. Oiwa and H. Watanabe and H. Takagi and K. Maeda and T. Hayashi and Y. Ioku", + title="{Mutual Authentication Protocol for HTTP}", + howpublished="RFC 8120 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8120", + pages="1--53", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8120.txt", + key="RFC 8120", + abstract={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.}, + keywords="HTTP, authentication", + doi="10.17487/RFC8120", + } + +@misc{rfc8121, + author="Y. Oiwa and H. Watanabe and H. Takagi and K. Maeda and T. Hayashi and Y. Ioku", + title="{Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)}", + howpublished="RFC 8121 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8121", + pages="1--17", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8121.txt", + key="RFC 8121", + abstract={This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).}, + keywords="HTTP, authentication", + doi="10.17487/RFC8121", + } + +@misc{rfc8122, + author="J. Lennox and C. Holmberg", + title="{Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)}", + howpublished="RFC 8122 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8122", + pages="1--18", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8122.txt", + key="RFC 8122", + abstract={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. This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.}, + keywords="SDP, TLS, Fingerprint, Offer, Answer", + doi="10.17487/RFC8122", + } + +@misc{rfc8123, + author="P. Dawes and C. Arunachalam", + title="{Requirements for Marking SIP Messages to be Logged}", + howpublished="RFC 8123 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8123", + pages="1--11", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8123.txt", + key="RFC 8123", + abstract={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. 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.}, + keywords="logme, troubleshooting, debug, logging", + doi="10.17487/RFC8123", + } + +@misc{rfc8124, + author="R. Ravindranath and G. Salgueiro", + title="{The Session Description Protocol (SDP) WebSocket Connection URI Attribute}", + howpublished="RFC 8124 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8124", + pages="1--12", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8124.txt", + key="RFC 8124", + abstract={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.}, + keywords="Secure WebSocket, Uniform Resource Identifier", + doi="10.17487/RFC8124", + } + +@misc{rfc8125, + author="J. Schmidt", + title="{Requirements for Password-Authenticated Key Agreement (PAKE) Schemes}", + howpublished="RFC 8125 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8125", + pages="1--10", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8125.txt", + key="RFC 8125", + abstract={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).}, + keywords="Password, Key Agreement, Password-Authenticated Key Agreement, Cryptographic Protocol", + doi="10.17487/RFC8125", + } + +@misc{rfc8126, + author="M. Cotton and B. Leiba and T. Narten", + title="{Guidelines for Writing an IANA Considerations Section in RFCs}", + howpublished="RFC 8126 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8126", + pages="1--47", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8126.txt", + key="RFC 8126", + abstract={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). 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. This is the third edition of this document; it obsoletes RFC 5226.}, + keywords="internet assigned numbers authority, values, implementations, code point, protocol constant, protocol parameter, codepoint", + doi="10.17487/RFC8126", + } + +@misc{rfc8127, + author="D. Patki and S. Gundavelli and J. Lee and Q. Fu and L. Bertz", + title="{Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor}", + howpublished="RFC 8127 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8127", + pages="1--14", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8127.txt", + key="RFC 8127", + abstract={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.}, + keywords="Binding Refresh, Heartbeat", + doi="10.17487/RFC8127", + } + +@misc{rfc8128, + author="C. Morgan", + title="{IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee}", + howpublished="RFC 8128 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8128", + pages="1--5", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8128.txt", + key="RFC 8128", + abstract={This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).}, + doi="10.17487/RFC8128", + } + +@misc{rfc8129, + author="A. Jain and N. Kinder and N. McCallum", + title="{Authentication Indicator in Kerberos Tickets}", + howpublished="RFC 8129 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8129", + pages="1--6", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8129.txt", + key="RFC 8129", + abstract={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.}, + doi="10.17487/RFC8129", + } + +@misc{rfc8130, + author="V. Demjanenko and D. Satterlee", + title="{RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec}", + howpublished="RFC 8130 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8130", + pages="1--30", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8130.txt", + key="RFC 8130", + abstract={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.}, + keywords="MELP, MELPe, MELP2400, MELP1200, MELP600, SCIP-210, SCIP210", + doi="10.17487/RFC8130", + } + +@misc{rfc8131, + author="X. Zhang and H. {Zheng (Ed.)} and R. {Gandhi (Ed.)} and Z. Ali and P. Brzozowski", + title="{RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing}", + howpublished="RFC 8131 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8131", + pages="1--15", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8131.txt", + key="RFC 8131", + abstract={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. 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.}, + keywords="Association Object, LSP Reversion, LSP Recovery, GMPLS Make-Before-Break, GMPLS 1+R, GMPLS 1+1+R", + doi="10.17487/RFC8131", + } + +@misc{rfc8132, + author="P. van der Stok and C. Bormann and A. Sehgal", + title="{PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)}", + howpublished="RFC 8132 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8132", + pages="1--21", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8132.txt", + key="RFC 8132", + abstract={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. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.}, + keywords="CoAP", + doi="10.17487/RFC8132", + } + +@misc{rfc8133, + author="S. Smyshlyaev. Ed. and E. Alekseev and I. Oshkin and V. Popov", + title="{The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol}", + howpublished="RFC 8133 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8133", + pages="1--51", + year=2017, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8133.txt", + key="RFC 8133", + abstract={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.}, + keywords="cryptography, secure channel, elliptic curve", + doi="10.17487/RFC8133", + } + +@misc{rfc8134, + author="C. Inacio and D. Miyamoto", + title="{Management Incident Lightweight Exchange (MILE) Implementation Report}", + howpublished="RFC 8134 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8134", + pages="1--16", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8134.txt", + key="RFC 8134", + abstract={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.}, + keywords="IODEF, RID, SCI, INCH, MILE, Implementation", + doi="10.17487/RFC8134", + } + +@misc{rfc8135, + author="M. Danielson and M. Nilsson", + title="{Complex Addressing in IPv6}", + howpublished="RFC 8135 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8135", + pages="1--16", + year=2017, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8135.txt", + key="RFC 8135", + abstract={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.}, + doi="10.17487/RFC8135", + } + +@misc{rfc8136, + author="B. Carpenter and R. Hinden", + title="{Additional Transition Functionality for IPv6}", + howpublished="RFC 8136 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8136", + pages="1--7", + year=2017, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8136.txt", + key="RFC 8136", + abstract={This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.}, + doi="10.17487/RFC8136", + } + +@misc{rfc8137, + author="T. Kivinen and P. Kinney", + title="{IEEE 802.15.4 Information Element for the IETF}", + howpublished="RFC 8137 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8137", + pages="1--7", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8137.txt", + key="RFC 8137", + abstract={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.}, + keywords="IE", + doi="10.17487/RFC8137", + } + +@misc{rfc8138, + author="P. {Thubert (Ed.)} and C. Bormann and L. Toutain and R. Cragie", + title="{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header}", + howpublished="RFC 8138 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8138", + pages="1--37", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8138.txt", + key="RFC 8138", + abstract={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.}, + doi="10.17487/RFC8138", + } + +@misc{rfc8139, + author="D. {Eastlake 3rd} and Y. Li and M. Umair and A. Banerjee and F. Hu", + title="{Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders}", + howpublished="RFC 8139 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8139", + pages="1--41", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8139.txt", + key="RFC 8139", + abstract={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.}, + keywords="DRB, VLAN mapping, inhibition, port shutdown, trill, TRansparent Interconnection of Lots of Links", + doi="10.17487/RFC8139", + } + +@misc{rfc8140, + author="A. Farrel", + title="{The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character}", + howpublished="RFC 8140 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8140", + pages="1--16", + year=2017, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8140.txt", + key="RFC 8140", + abstract={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. 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''. 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.}, + doi="10.17487/RFC8140", + } + +@misc{rfc8141, + author="P. Saint-Andre and J. Klensin", + title="{Uniform Resource Names (URNs)}", + howpublished="RFC 8141 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8141", + pages="1--40", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8141.txt", + key="RFC 8141", + abstract={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.}, + keywords="Uniform Resource Name, URN, Uniform Resource Identifier, URI", + doi="10.17487/RFC8141", + } + +@misc{rfc8142, + author="S. Gillies", + title="{GeoJSON Text Sequences}", + howpublished="RFC 8142 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8142", + pages="1--5", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8142.txt", + key="RFC 8142", + abstract={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.}, + keywords="JSON, Geospatial, JavaScript Object Notation", + doi="10.17487/RFC8142", + } + +@misc{rfc8143, + author="J. Elie", + title="{Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)}", + howpublished="RFC 8143 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8143", + pages="1--13", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8143.txt", + key="RFC 8143", + abstract={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.}, + keywords="NNTP, Usenet, NetNews, TLS, STARTTLS", + doi="10.17487/RFC8143", + } + +@misc{rfc8144, + author="K. Murchison", + title="{Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)}", + howpublished="RFC 8144 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8144", + pages="1--28", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8144.txt", + key="RFC 8144", + abstract={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.}, + keywords="http, prefer, webav, caldav", + doi="10.17487/RFC8144", + } + +@misc{rfc8145, + author="D. Wessels and W. Kumari and P. Hoffman", + title="{Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)}", + howpublished="RFC 8145 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8145", + pages="1--13", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8145.txt", + key="RFC 8145", + abstract={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.}, + keywords="DNS, DNSSEC, Trust Anchor", + doi="10.17487/RFC8145", + } + +@misc{rfc8146, + author="D. Harkins", + title="{Adding Support for Salted Password Databases to EAP-pwd}", + howpublished="RFC 8146 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8146", + pages="1--11", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8146.txt", + key="RFC 8146", + abstract={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.}, + keywords="Password-Authenticated Key Exchange, PAKE, Dictionary Attack, Authentication EAP", + doi="10.17487/RFC8146", + } + +@misc{rfc8147, + author="R. Gellens and H. Tschofenig", + title="{Next-Generation Pan-European eCall}", + howpublished="RFC 8147 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8147", + pages="1--43", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8147.txt", + key="RFC 8147", + abstract={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. 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. 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.}, + keywords="emergency, call, calls, emergency call, emergency calls, vehicle, acn, aacn, automatic crash notification, automatic collision notification, advanced automatic crash notification, advanced automatic collision notification, crash, vehicle-initiated", + doi="10.17487/RFC8147", + } + +@misc{rfc8148, + author="R. Gellens and B. Rosen and H. Tschofenig", + title="{Next-Generation Vehicle-Initiated Emergency Calls}", + howpublished="RFC 8148 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8148", + pages="1--40", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8148.txt", + key="RFC 8148", + abstract={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. 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. This document reuses th e 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.}, + keywords="emergency, call, calls, emergency call, emergency calls, vehicle, acn, aacn, automatic crash notification, automatic collision notification, advanced automatic crash notification, advanced automatic collision notification, crash, vehicle-initiated, ecall", + doi="10.17487/RFC8148", + } + +@misc{rfc8149, + author="T. {Saad (Ed.)} and R. {Gandhi (Ed.)} and Z. Ali and R. Venator and Y. Kamite", + title="{RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)}", + howpublished="RFC 8149 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8149", + pages="1--17", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8149.txt", + key="RFC 8149", + abstract={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.}, + keywords="RSVP fragmentation, RSVP fragment identifier, P2MP-TE tree reoptimization, P2MP-TE tree re-evaluation, Preferable P2MP-TE tree, Inter-domain P2MP-TE", + doi="10.17487/RFC8149", + } + +@misc{rfc8150, + author="S. Kingston Smiler and M. Venkatesan and D. King and S. Aldrin and J. Ryoo", + title="{MPLS Transport Profile Linear Protection MIB}", + howpublished="RFC 8150 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8150", + pages="1--48", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8150.txt", + key="RFC 8150", + abstract={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.}, + keywords="Network Management, Management Information Base, MIB, SMIv2", + doi="10.17487/RFC8150", + } + +@misc{rfc8151, + author="L. Yong and L. Dunbar and M. Toy and A. Isaac and V. Manral", + title="{Use Cases for Data Center Network Virtualization Overlay Networks}", + howpublished="RFC 8151 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8151", + pages="1--16", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8151.txt", + key="RFC 8151", + abstract={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.}, + doi="10.17487/RFC8151", + } + +@misc{rfc8152, + author="J. Schaad", + title="{CBOR Object Signing and Encryption (COSE)}", + howpublished="RFC 8152 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8152", + pages="1--121", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8152.txt", + key="RFC 8152", + abstract={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.}, + keywords="CoAP, ECC, Elliptic Curve", + doi="10.17487/RFC8152", + } + +@misc{rfc8153, + author="H. Flanagan", + title="{Digital Preservation Considerations for the RFC Series}", + howpublished="RFC 8153 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8153", + pages="1--18", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8153.txt", + key="RFC 8153", + abstract={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.}, + keywords="archive, archiving", + doi="10.17487/RFC8153", + } + +@misc{rfc8154, + author="C. Hellwig", + title="{Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout}", + howpublished="RFC 8154 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8154", + pages="1--30", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8154.txt", + key="RFC 8154", + abstract={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.}, + keywords="NFSv4", + doi="10.17487/RFC8154", + } + +@misc{rfc8155, + author="P. Patil and T. Reddy and D. Wing", + title="{Traversal Using Relays around NAT (TURN) Server Auto Discovery}", + howpublished="RFC 8155 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8155", + pages="1--16", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8155.txt", + key="RFC 8155", + abstract={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. This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.}, + doi="10.17487/RFC8155", + } + +@misc{rfc8156, + author="T. Mrugalski and K. Kinnear", + title="{DHCPv6 Failover Protocol}", + howpublished="RFC 8156 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8156", + pages="1--96", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8156.txt", + key="RFC 8156", + abstract={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).}, + keywords="DHCPv6, Failover", + doi="10.17487/RFC8156", + } + +@misc{rfc8157, + author="N. Leymann and C. Heidemann and M. Zhang and B. Sarikaya and M. Cullen", + title="{Huawei's GRE Tunnel Bonding Protocol}", + howpublished="RFC 8157 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8157", + pages="1--44", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8157.txt", + key="RFC 8157", + abstract={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. 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.}, + keywords="Hybrid Access, Bandwidth Aggregation, Bonding Tunnel, GRE Channel, Hybrid Access Aggregation Point, Home Gateway", + doi="10.17487/RFC8157", + } + +@misc{rfc8158, + author="S. Sivakumar and R. Penno", + title="{IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events}", + howpublished="RFC 8158 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8158", + pages="1--34", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8158.txt", + key="RFC 8158", + abstract={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.}, + keywords="template", + doi="10.17487/RFC8158", + } + +@misc{rfc8159, + author="M. {Konstantynowicz (Ed.)} and G. {Heron (Ed.)} and R. Schatzmayr and W. Henderickx", + title="{Keyed IPv6 Tunnel}", + howpublished="RFC 8159 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8159", + pages="1--12", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8159.txt", + key="RFC 8159", + abstract={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.}, + keywords="L2TPv3, pseudowire", + doi="10.17487/RFC8159", + } + +@misc{rfc8160, + author="S. Tatham and D. Tucker", + title="{IUTF8 Terminal Mode in Secure Shell (SSH)}", + howpublished="RFC 8160 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8160", + pages="1--4", + year=2017, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8160.txt", + key="RFC 8160", + abstract={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.}, + keywords="Secure Shell, SSH", + doi="10.17487/RFC8160", + } + +@misc{rfc8161, + author="W. Cerveny and R. Bonica and R. Thomas", + title="{Benchmarking the Neighbor Discovery Protocol}", + howpublished="RFC 8161 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8161", + pages="1--17", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8161.txt", + key="RFC 8161", + abstract={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.}, + keywords="IPv6, Scaling, NDP", + doi="10.17487/RFC8161", + } + +@misc{rfc8162, + author="P. Hoffman and J. Schlyter", + title="{Using Secure DNS to Associate Certificates with Domain Names for S/MIME}", + howpublished="RFC 8162 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8162", + pages="1--11", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8162.txt", + key="RFC 8162", + abstract={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.}, + doi="10.17487/RFC8162", + } + +@misc{rfc8163, + author="K. {Lynn (Ed.)} and J. Martocci and C. Neilson and S. Donaldson", + title="{Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks}", + howpublished="RFC 8163 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8163", + pages="1--27", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8163.txt", + key="RFC 8163", + abstract={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.}, + doi="10.17487/RFC8163", + } + +@misc{rfc8164, + author="M. Nottingham and M. Thomson", + title="{Opportunistic Security for HTTP/2}", + howpublished="RFC 8164 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8164", + pages="1--10", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8164.txt", + key="RFC 8164", + abstract={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.}, + keywords="Opportunistic Security, HTTP", + doi="10.17487/RFC8164", + } + +@misc{rfc8165, + author="T. Hardie", + title="{Design Considerations for Metadata Insertion}", + howpublished="RFC 8165 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8165", + pages="1--7", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8165.txt", + key="RFC 8165", + abstract={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.}, + keywords="surveillance, proxy, proxying, middlebox", + doi="10.17487/RFC8165", + } + +@misc{rfc8166, + author="C. {Lever (Ed.)} and W. Simpson and T. Talpey", + title="{Remote Direct Memory Access Transport for Remote Procedure Call Version 1}", + howpublished="RFC 8166 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8166", + pages="1--55", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8166.txt", + key="RFC 8166", + abstract={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.}, + keywords="RPC-over-RDMA", + doi="10.17487/RFC8166", + } + +@misc{rfc8167, + author="C. Lever", + title="{Bidirectional Remote Procedure Call on RPC-over-RDMA Transports}", + howpublished="RFC 8167 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8167", + pages="1--13", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8167.txt", + key="RFC 8167", + abstract={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.}, + keywords="NFS-over-RDMA, RPC-over-RDMA", + doi="10.17487/RFC8167", + } + +@misc{rfc8168, + author="T. Li and C. Liu and Y. Cui", + title="{DHCPv6 Prefix-Length Hint Issues}", + howpublished="RFC 8168 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8168", + pages="1--9", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8168.txt", + key="RFC 8168", + abstract={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.}, + keywords="DHCPv6, Dynamic Host Configuration Protocol, IPv6, Prefix, Prefix Delegation, Prefix Length, Hint, Address Allocation", + doi="10.17487/RFC8168", + } + +@misc{rfc8169, + author="G. Mirsky and S. Ruffini and E. Gray and J. Drake and S. Bryant and A. Vainshtein", + title="{Residence Time Measurement in MPLS Networks}", + howpublished="RFC 8169 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8169", + pages="1--30", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8169.txt", + key="RFC 8169", + abstract={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. 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.}, + keywords="G-ACh, Resident Time, MPLS", + doi="10.17487/RFC8169", + } + +@misc{rfc8170, + author="D. {Thaler (Ed.)}", + title="{Planning for Protocol Adoption and Subsequent Transitions}", + howpublished="RFC 8170 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8170", + pages="1--22", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8170.txt", + key="RFC 8170", + abstract={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.}, + keywords="transition plan", + doi="10.17487/RFC8170", + } + +@misc{rfc8171, + author="D. {Eastlake 3rd} and L. Dunbar and R. Perlman and Y. Li", + title="{Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms}", + howpublished="RFC 8171 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8171", + pages="1--55", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8171.txt", + key="RFC 8171", + abstract={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.}, + keywords="Push, Pull, ESADI, ES-IS", + doi="10.17487/RFC8171", + } + +@misc{rfc8172, + author="A. Morton", + title="{Considerations for Benchmarking Virtual Network Functions and Their Infrastructure}", + howpublished="RFC 8172 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8172", + pages="1--15", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8172.txt", + key="RFC 8172", + abstract={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.}, + doi="10.17487/RFC8172", + } + +@misc{rfc8173, + author="V. Shankarkumar and L. Montini and T. Frost and G. Dowd", + title="{Precision Time Protocol Version 2 (PTPv2) Management Information Base}", + howpublished="RFC 8173 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8173", + pages="1--64", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8173.txt", + key="RFC 8173", + abstract={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. 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.}, + doi="10.17487/RFC8173", + } + +@misc{rfc8174, + author="B. Leiba", + title="{Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words}", + howpublished="RFC 8174 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8174", + pages="1--4", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8174.txt", + key="RFC 8174", + abstract={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.}, + doi="10.17487/RFC8174", + } + +@misc{rfc8175, + author="S. Ratliff and S. Jury and D. Satterwhite and R. Taylor and B. Berry", + title="{Dynamic Link Exchange Protocol (DLEP)}", + howpublished="RFC 8175 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8175", + pages="1--82", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8175.txt", + key="RFC 8175", + abstract={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.}, + doi="10.17487/RFC8175", + } + +@misc{rfc8176, + author="M. Jones and P. Hunt and A. Nadalin", + title="{Authentication Method Reference Values}", + howpublished="RFC 8176 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8176", + pages="1--15", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8176.txt", + key="RFC 8176", + abstract={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.}, + keywords="Authentication Method Reference, Authentication Method,", + doi="10.17487/RFC8176", + } + +@misc{rfc8177, + author="A. {Lindem (Ed.)} and Y. Qu and D. Yeung and I. Chen and J. Zhang", + title="{YANG Data Model for Key Chains}", + howpublished="RFC 8177 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8177", + pages="1--25", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8177.txt", + key="RFC 8177", + abstract={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.}, + doi="10.17487/RFC8177", + } + +@misc{rfc8178, + author="D. Noveck", + title="{Rules for NFSv4 Extensions and Minor Versions}", + howpublished="RFC 8178 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8178", + pages="1--26", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8178.txt", + key="RFC 8178", + abstract={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.}, + doi="10.17487/RFC8178", + } + +@misc{rfc8179, + author="S. Bradner and J. Contreras", + title="{Intellectual Property Rights in IETF Technology}", + howpublished="RFC 8179 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8179", + pages="1--26", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8179.txt", + key="RFC 8179", + abstract={The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information 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.}, + keywords="IPR, copyright", + doi="10.17487/RFC8179", + } + +@misc{rfc8180, + author="X. {Vilajosana (Ed.)} and K. Pister and T. Watteyne", + title="{Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration}", + howpublished="RFC 8180 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8180", + pages="1--28", + year=2017, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8180.txt", + key="RFC 8180", + abstract={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.}, + doi="10.17487/RFC8180", + } + +@misc{rfc8181, + author="S. Weiler and A. Sonalker and R. Austein", + title="{A Publication Protocol for the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 8181 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8181", + pages="1--21", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8181.txt", + key="RFC 8181", + abstract={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.}, + keywords="SIDR", + doi="10.17487/RFC8181", + } + +@misc{rfc8182, + author="T. Bruijnzeels and O. Muravskiy and B. Weber and R. Austein", + title="{The RPKI Repository Delta Protocol (RRDP)}", + howpublished="RFC 8182 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8182", + pages="1--24", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8182.txt", + key="RFC 8182", + abstract={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.}, + doi="10.17487/RFC8182", + } + +@misc{rfc8183, + author="R. Austein", + title="{An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services}", + howpublished="RFC 8183 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8183", + pages="1--23", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8183.txt", + key="RFC 8183", + abstract={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. 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.}, + keywords="RPKI", + doi="10.17487/RFC8183", + } + +@misc{rfc8184, + author="W. Cheng and L. Wang and H. Li and S. Davari and J. Dong", + title="{Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires}", + howpublished="RFC 8184 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8184", + pages="1--11", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8184.txt", + key="RFC 8184", + abstract={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.}, + keywords="mpls, mpls-tp", + doi="10.17487/RFC8184", + } + +@misc{rfc8185, + author="W. Cheng and L. Wang and H. Li and J. Dong and A. D'Alessandro", + title="{Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection}", + howpublished="RFC 8185 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8185", + pages="1--17", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8185.txt", + key="RFC 8185", + abstract={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.}, + keywords="mpls, mpls-tp", + doi="10.17487/RFC8185", + } + +@misc{rfc8186, + author="G. Mirsky and I. Meilik", + title="{Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)}", + howpublished="RFC 8186 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8186", + pages="1--8", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8186.txt", + key="RFC 8186", + abstract={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.}, + keywords="IPPM, TWAMP, IEEE 1588, PTPv2", + doi="10.17487/RFC8186", + } + +@misc{rfc8187, + author="J. Reschke", + title="{Indicating Character Encoding and Language for HTTP Header Field Parameters}", + howpublished="RFC 8187 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8187", + pages="1--13", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8187.txt", + key="RFC 8187", + abstract={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. This document obsoletes RFC 5987.}, + doi="10.17487/RFC8187", + } + +@misc{rfc8188, + author="M. Thomson", + title="{Encrypted Content-Encoding for HTTP}", + howpublished="RFC 8188 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8188", + pages="1--16", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8188.txt", + key="RFC 8188", + abstract={This memo introduces a content coding for HTTP that allows message payloads to be encrypted.}, + keywords="http, content coding, content encoding, encryption aead", + doi="10.17487/RFC8188", + } + +@misc{rfc8189, + author="S. Randriamasy and W. Roome and N. Schwan", + title="{Multi-Cost Application-Layer Traffic Optimization (ALTO)}", + howpublished="RFC 8189 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8189", + pages="1--29", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8189.txt", + key="RFC 8189", + abstract={The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints. 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.}, + keywords="ALTO Information Resources, Network Map, PID, Filtered Network Map, Endpoint Property Service, Endpoint Cost Service, Multi-Cost, Filtered Multi-Cost Map, Multi-Cost Data Format, Testable Cost Types, or-constraints", + doi="10.17487/RFC8189", + } + +@misc{rfc8190, + author="R. Bonica and M. Cotton and B. Haberman and L. Vegoda", + title="{Updates to the Special-Purpose IP Address Registries}", + howpublished="RFC 8190 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8190", + pages="1--6", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8190.txt", + key="RFC 8190", + abstract={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. This memo updates RFC 6890.}, + doi="10.17487/RFC8190", + } + +@misc{rfc8191, + author="Z. Yan and J. Lee and X. Lee", + title="{Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)}", + howpublished="RFC 8191 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8191", + pages="1--10", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8191.txt", + key="RFC 8191", + abstract={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.}, + keywords="PMIPv6, HNP, HNP renumbering, LMA handover", + doi="10.17487/RFC8191", + } + +@misc{rfc8192, + author="S. Hares and D. Lopez and M. Zarny and C. Jacquenet and R. Kumar and J. Jeong", + title="{Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases}", + howpublished="RFC 8192 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8192", + pages="1--29", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8192.txt", + key="RFC 8192", + abstract={This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases.}, + keywords="I2NSF", + doi="10.17487/RFC8192", + } + +@misc{rfc8193, + author="T. Burbridge and P. Eardley and M. Bagnulo and J. Schoenwaelder", + title="{Information Model for Large-Scale Measurement Platforms (LMAPs)}", + howpublished="RFC 8193 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8193", + pages="1--53", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8193.txt", + key="RFC 8193", + abstract={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.}, + doi="10.17487/RFC8193", + } + +@misc{rfc8194, + author="J. Schoenwaelder and V. Bajpai", + title="{A YANG Data Model for LMAP Measurement Agents}", + howpublished="RFC 8194 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8194", + pages="1--59", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8194.txt", + key="RFC 8194", + abstract={This document defines a data model for Large-Scale Measurement Platforms (LMAPs). The data model is defined using the YANG data modeling language.}, + keywords="LMAP, YANG", + doi="10.17487/RFC8194", + } + +@misc{rfc8195, + author="J. Snijders and J. Heasley and M. Schmidt", + title="{Use of BGP Large Communities}", + howpublished="RFC 8195 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8195", + pages="1--15", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8195.txt", + key="RFC 8195", + abstract={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.}, + keywords="large, BGP, communities", + doi="10.17487/RFC8195", + } + +@misc{rfc8196, + author="B. {Liu (Ed.)} and L. Ginsberg and B. Decraene and I. Farrer and M. Abrahamsson", + title="{IS-IS Autoconfiguration}", + howpublished="RFC 8196 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8196", + pages="1--15", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8196.txt", + key="RFC 8196", + abstract={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.}, + keywords="isis auto-configuration", + doi="10.17487/RFC8196", + } + +@misc{rfc8197, + author="H. Schulzrinne", + title="{A SIP Response Code for Unwanted Calls}", + howpublished="RFC 8197 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8197", + pages="1--8", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8197.txt", + key="RFC 8197", + abstract={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.}, + keywords="SIP, robocall, unwanted, response code", + doi="10.17487/RFC8197", + } + +@misc{rfc8198, + author="K. Fujiwara and A. Kato and W. Kumari", + title="{Aggressive Use of DNSSEC-Validated Cache}", + howpublished="RFC 8198 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8198", + pages="1--13", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8198.txt", + key="RFC 8198", + abstract={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. 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.}, + keywords="Negative cache, NCACHE, NSEC, NSEC3", + doi="10.17487/RFC8198", + } + +@misc{rfc8199, + author="D. Bogdanovic and B. Claise and C. Moberg", + title="{YANG Module Classification}", + howpublished="RFC 8199 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8199", + pages="1--11", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8199.txt", + key="RFC 8199", + abstract={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. 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. This document describes a set of concepts and associated terms to support consistent classification of YANG modules.}, + keywords="service, element, standard, vendor, user, controller, orchestrator", + doi="10.17487/RFC8199", + } + +@misc{rfc8200, + author="S. Deering and R. Hinden", + title="{Internet Protocol, Version 6 (IPv6) Specification}", + howpublished="RFC 8200 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8200", + pages="1--42", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8200.txt", + key="RFC 8200", + abstract={This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.}, + keywords="IPv6, internet, protocol, next, generation, ipng, flow label", + doi="10.17487/RFC8200", + } + +@misc{rfc8201, + author="J. McCann and S. Deering and J. Mogul and R. {Hinden (Ed.)}", + title="{Path MTU Discovery for IP version 6}", + howpublished="RFC 8201 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8201", + pages="1--19", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8201.txt", + key="RFC 8201", + abstract={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.}, + keywords="MTU-IPv6, Internet, Protocol, IPv6, link MTU, path MTU, PMTU, Path MTU Discovery", + doi="10.17487/RFC8201", + } + +@misc{rfc8202, + author="L. Ginsberg and S. Previdi and W. Henderickx", + title="{IS-IS Multi-Instance}", + howpublished="RFC 8202 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8202", + pages="1--16", + year=2017, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8202.txt", + key="RFC 8202", + abstract={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. 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. This document obsoletes RFC 6822.}, + doi="10.17487/RFC8202", + } + +@misc{rfc8203, + author="J. Snijders and J. Heitz and J. Scudder", + title="{BGP Administrative Shutdown Communication}", + howpublished="RFC 8203 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8203", + pages="1--6", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8203.txt", + key="RFC 8203", + abstract={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.}, + keywords="BGP, cease, shutdown", + doi="10.17487/RFC8203", + } + +@misc{rfc8204, + author="M. Tahhan and B. O'Mahony and A. Morton", + title="{Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV)}", + howpublished="RFC 8204 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8204", + pages="1--24", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8204.txt", + key="RFC 8204", + abstract={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.}, + doi="10.17487/RFC8204", + } + +@misc{rfc8205, + author="M. {Lepinski (Ed.)} and K. {Sriram (Ed.)}", + title="{BGPsec Protocol Specification}", + howpublished="RFC 8205 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8205", + pages="1--45", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + note="Updated by RFC 8206", +url="https://www.rfc-editor.org/rfc/rfc8205.txt", + key="RFC 8205", + abstract={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.}, + keywords="BGP, BGPsec, BGP AS-path protection, BGP Security", + doi="10.17487/RFC8205", + } + +@misc{rfc8206, + author="W. George and S. Murphy", + title="{BGPsec Considerations for Autonomous System (AS) Migration}", + howpublished="RFC 8206 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8206", + pages="1--16", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8206.txt", + key="RFC 8206", + abstract={This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.}, + keywords="as-migration, SIDR, BGPsec, AS\_PATH", + doi="10.17487/RFC8206", + } + +@misc{rfc8207, + author="R. Bush", + title="{BGPsec Operational Considerations}", + howpublished="RFC 8207 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8207", + pages="1--10", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8207.txt", + key="RFC 8207", + abstract={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.}, + keywords="BGP, RPKI, Routing, Security", + doi="10.17487/RFC8207", + } + +@misc{rfc8208, + author="S. Turner and O. Borchert", + title="{BGPsec Algorithms, Key Formats, and Signature Formats}", + howpublished="RFC 8208 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8208", + pages="1--19", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8208.txt", + key="RFC 8208", + abstract={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''). 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.}, + doi="10.17487/RFC8208", + } + +@misc{rfc8209, + author="M. Reynolds and S. Turner and S. Kent", + title="{A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests}", + howpublished="RFC 8209 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8209", + pages="1--15", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8209.txt", + key="RFC 8209", + abstract={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 auth orized 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).}, + doi="10.17487/RFC8209", + } + +@misc{rfc8210, + author="R. Bush and R. Austein", + title="{The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1}", + howpublished="RFC 8210 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8210", + pages="1--35", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8210.txt", + key="RFC 8210", + abstract={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. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.}, + doi="10.17487/RFC8210", + } + +@misc{rfc8211, + author="S. Kent and D. Ma", + title="{Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 8211 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8211", + pages="1--26", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8211.txt", + key="RFC 8211", + abstract={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.}, + keywords="BGP Security", + doi="10.17487/RFC8211", + } + +@misc{rfc8212, + author="J. Mauch and J. Snijders and G. Hankins", + title="{Default External BGP (EBGP) Route Propagation Behavior without Policies}", + howpublished="RFC 8212 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8212", + pages="1--7", + year=2017, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8212.txt", + key="RFC 8212", + abstract={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.}, + keywords="reject, BGP, EBGP", + doi="10.17487/RFC8212", + } + +@misc{rfc8213, + author="B. Volz and Y. Pal", + title="{Security of Messages Exchanged between Servers and Relay Agents}", + howpublished="RFC 8213 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8213", + pages="1--8", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8213.txt", + key="RFC 8213", + abstract={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.}, + doi="10.17487/RFC8213", + } + +@misc{rfc8214, + author="S. Boutros and A. Sajassi and S. Salam and J. Drake and J. Rabadan", + title="{Virtual Private Wire Service Support in Ethernet VPN}", + howpublished="RFC 8214 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8214", + pages="1--17", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8214.txt", + key="RFC 8214", + abstract={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.}, + doi="10.17487/RFC8214", + } + +@misc{rfc8215, + author="T. Anderson", + title="{Local-Use IPv4/IPv6 Translation Prefix}", + howpublished="RFC 8215 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8215", + pages="1--7", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8215.txt", + key="RFC 8215", + abstract={This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.}, + keywords="IPv6 transition, IVI, MAP, NAT64, SIIT, SIIT-DC, Transition", + doi="10.17487/RFC8215", + } + +@misc{rfc8216, + author="R. {Pantos (Ed.)} and W. May", + title="{HTTP Live Streaming}", + howpublished="RFC 8216 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8216", + pages="1--60", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8216.txt", + key="RFC 8216", + abstract={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.}, + keywords="HTML, streaming, media", + doi="10.17487/RFC8216", + } + +@misc{rfc8217, + author="R. Sparks", + title="{Clarifications for When to Use the name-addr Production in SIP Messages}", + howpublished="RFC 8217 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8217", + pages="1--6", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8217.txt", + key="RFC 8217", + abstract={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. 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).}, + doi="10.17487/RFC8217", + } + +@misc{rfc8218, + author="J. Yi and B. Parrein", + title="{Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)}", + howpublished="RFC 8218 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8218", + pages="1--26", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8218.txt", + key="RFC 8218", + abstract={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.}, + keywords="MANET", + doi="10.17487/RFC8218", + } + +@misc{rfc8219, + author="M. Georgescu and L. Pislaru and G. Lencse", + title="{Benchmarking Methodology for IPv6 Transition Technologies}", + howpublished="RFC 8219 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8219", + pages="1--30", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8219.txt", + key="RFC 8219", + abstract={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.}, + keywords="Single Translation Technologies, Double Translation Technologies, Encapsulation Technologies, NAT64, DNS64, MAP-E, MAP-T, DSLite, 464XLAT, 6PE, DNS Resolution Performance, Overload Scalability, Typical Latency, Worst Case Latency, PDV, IPDV", + doi="10.17487/RFC8219", + } + +@misc{rfc8220, + author="O. Dornon and J. Kotalwar and V. Hemige and R. Qiu and Z. Zhang", + title="{Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)}", + howpublished="RFC 8220 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8220", + pages="1--43", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8220.txt", + key="RFC 8220", + abstract={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. 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. This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune m essages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.}, + keywords="multicast", + doi="10.17487/RFC8220", + } + +@misc{rfc8221, + author="P. Wouters and D. Migault and J. Mattsson and Y. Nir and T. Kivinen", + title="{Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)}", + howpublished="RFC 8221 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8221", + pages="1--15", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8221.txt", + key="RFC 8221", + abstract={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.}, + keywords="IPsec, IKE", + doi="10.17487/RFC8221", + } + +@misc{rfc8222, + author="A. Sullivan", + title="{Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery}", + howpublished="RFC 8222 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8222", + pages="1--11", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8222.txt", + key="RFC 8222", + abstract={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.}, + keywords="DNS, mDNS, DNS-SD", + doi="10.17487/RFC8222", + } + +@misc{rfc8223, + author="S. Esale and R. Torvi and L. Jalil and U. Chunduri and K. Raza", + title="{Application-Aware Targeted LDP}", + howpublished="RFC 8223 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8223", + pages="1--18", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8223.txt", + key="RFC 8223", + abstract={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 bindi ngs over the session.}, + doi="10.17487/RFC8223", + } + +@misc{rfc8224, + author="J. Peterson and C. Jennings and E. Rescorla and C. Wendt", + title="{Authenticated Identity Management in the Session Initiation Protocol (SIP)}", + howpublished="RFC 8224 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8224", + pages="1--46", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8224.txt", + key="RFC 8224", + abstract={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. This document obsoletes RFC 4474.}, + keywords="SIP, Secure Origin Identification, Communication Security, RTCWeb, Certificates, Real-Time Communication", + doi="10.17487/RFC8224", + } + +@misc{rfc8225, + author="C. Wendt and J. Peterson", + title="{PASSporT: Personal Assertion Token}", + howpublished="RFC 8225 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8225", + pages="1--25", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8225.txt", + key="RFC 8225", + abstract={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.}, + doi="10.17487/RFC8225", + } + +@misc{rfc8226, + author="J. Peterson and S. Turner", + title="{Secure Telephone Identity Credentials: Certificates}", + howpublished="RFC 8226 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8226", + pages="1--24", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8226.txt", + key="RFC 8226", + abstract={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.}, + keywords="TNAuthorizationList, JWTClaimConstraints", + doi="10.17487/RFC8226", + } + +@misc{rfc8227, + author="W. Cheng and L. Wang and H. Li and H. van Helvoort and J. Dong", + title="{MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology}", + howpublished="RFC 8227 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8227", + pages="1--56", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8227.txt", + key="RFC 8227", + abstract={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.}, + keywords="wrapping protection, short-wrapping protection, steering protection, ring protection, shared ring protection, protection switching", + doi="10.17487/RFC8227", + } + +@misc{rfc8228, + author="A. Freytag", + title="{Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels}", + howpublished="RFC 8228 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8228", + pages="1--24", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8228.txt", + key="RFC 8228", + abstract={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.}, + keywords="LGR, Variant, IDN", + doi="10.17487/RFC8228", + } + +@misc{rfc8229, + author="T. Pauly and S. Touati and R. Mantha", + title="{TCP Encapsulation of IKE and IPsec Packets}", + howpublished="RFC 8229 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8229", + pages="1--25", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8229.txt", + key="RFC 8229", + abstract={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.}, + keywords="IKE, IKEv2, IPsec, TCP", + doi="10.17487/RFC8229", + } + +@misc{rfc8230, + author="M. Jones", + title="{Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages}", + howpublished="RFC 8230 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8230", + pages="1--12", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8230.txt", + key="RFC 8230", + abstract={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.}, + keywords="Cryptography, Digital Signature, Encryption", + doi="10.17487/RFC8230", + } + +@misc{rfc8231, + author="E. Crabbe and I. Minei and J. Medved and R. Varga", + title="{Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE}", + howpublished="RFC 8231 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8231", + pages="1--57", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8231.txt", + key="RFC 8231", + abstract={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. 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.}, + keywords="Stateful PCE", + doi="10.17487/RFC8231", + } + +@misc{rfc8232, + author="E. Crabbe and I. Minei and J. Medved and R. Varga and X. Zhang and D. Dhody", + title="{Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE}", + howpublished="RFC 8232 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8232", + pages="1--26", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8232.txt", + key="RFC 8232", + abstract={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.}, + keywords="Stateful PCE, state synchronization, optimization", + doi="10.17487/RFC8232", + } + +@misc{rfc8233, + author="D. Dhody and Q. Wu and V. Manral and Z. Ali and K. Kumaki", + title="{Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)}", + howpublished="RFC 8233 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8233", + pages="1--31", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8233.txt", + key="RFC 8233", + abstract={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. 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 bandwidt h utilization as constraints for end-to-end path computation.}, + keywords="PCE, PCEP, service-aware, metric, BU, LBU, LRBU", + doi="10.17487/RFC8233", + } + +@misc{rfc8234, + author="J. Ryoo and T. Cheung and H. van Helvoort and I. Busi and G. Wen", + title="{Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode}", + howpublished="RFC 8234 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8234", + pages="1--9", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8234.txt", + key="RFC 8234", + abstract={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.}, + keywords="APS mode, initialization, mpls-tp linear protection", + doi="10.17487/RFC8234", + } + +@misc{rfc8235, + author="F. {Hao (Ed.)}", + title="{Schnorr Non-interactive Zero-Knowledge Proof}", + howpublished="RFC 8235 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8235", + pages="1--13", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8235.txt", + key="RFC 8235", + abstract={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.}, + keywords="Zero-Knowledge Proof, Schnorr NIZK proof, Identification protocol", + doi="10.17487/RFC8235", + } + +@misc{rfc8236, + author="F. {Hao (Ed.)}", + title="{J-PAKE: Password-Authenticated Key Exchange by Juggling}", + howpublished="RFC 8236 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8236", + pages="1--15", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8236.txt", + key="RFC 8236", + abstract={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.}, + doi="10.17487/RFC8236", + } + +@misc{rfc8237, + author="L. Martini and G. Swallow and E. Bellagamba", + title="{MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs}", + howpublished="RFC 8237 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8237", + pages="1--20", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8237.txt", + key="RFC 8237", + abstract={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. 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.}, + doi="10.17487/RFC8237", + } + +@misc{rfc8238, + author="L. Avramov and J. Rapp", + title="{Data Center Benchmarking Terminology}", + howpublished="RFC 8238 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8238", + pages="1--20", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8238.txt", + key="RFC 8238", + abstract={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.}, + doi="10.17487/RFC8238", + } + +@misc{rfc8239, + author="L. Avramov and J. Rapp", + title="{Data Center Benchmarking Methodology}", + howpublished="RFC 8239 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8239", + pages="1--19", + year=2017, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8239.txt", + key="RFC 8239", + abstract={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.}, + doi="10.17487/RFC8239", + } + +@misc{rfc8240, + author="H. Tschofenig and S. Farrell", + title="{Report from the Internet of Things Software Update (IoTSU) Workshop 2016}", + howpublished="RFC 8240 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8240", + pages="1--27", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8240.txt", + key="RFC 8240", + abstract={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. 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.}, + keywords="Security, Firmware Updates, Software Updates, Internet of Things", + doi="10.17487/RFC8240", + } + +@misc{rfc8241, + author="S. Hares and D. Migault and J. Halpern", + title="{Interface to the Routing System (I2RS) Security-Related Requirements}", + howpublished="RFC 8241 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8241", + pages="1--20", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8241.txt", + key="RFC 8241", + abstract={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.}, + doi="10.17487/RFC8241", + } + +@misc{rfc8242, + author="J. Haas and S. Hares", + title="{Interface to the Routing System (I2RS) Ephemeral State Requirements}", + howpublished="RFC 8242 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8242", + pages="1--12", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8242.txt", + key="RFC 8242", + abstract={``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.}, + doi="10.17487/RFC8242", + } + +@misc{rfc8243, + author="R. Perlman and D. {Eastlake 3rd} and M. Zhang and A. Ghanwani and H. Zhai", + title="{Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)}", + howpublished="RFC 8243 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8243", + pages="1--29", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8243.txt", + key="RFC 8243", + abstract={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? 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.}, + keywords="aggregaged nickname, unique nickname", + doi="10.17487/RFC8243", + } + +@misc{rfc8244, + author="T. Lemon and R. Droms and W. Kumari", + title="{Special-Use Domain Names Problem Statement}", + howpublished="RFC 8244 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8244", + pages="1--25", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8244.txt", + key="RFC 8244", + abstract={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. 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.}, + keywords="SUN, SUTLD, RFC6761", + doi="10.17487/RFC8244", + } + +@misc{rfc8245, + author="T. Clausen and C. Dearlove and U. Herberg and H. Rogge", + title="{Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444}", + howpublished="RFC 8245 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8245", + pages="1--29", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8245.txt", + key="RFC 8245", + abstract={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.}, + keywords="MANET", + doi="10.17487/RFC8245", + } + +@misc{rfc8246, + author="P. McManus", + title="{HTTP Immutable Responses}", + howpublished="RFC 8246 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8246", + pages="1--6", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8246.txt", + key="RFC 8246", + abstract={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.}, + doi="10.17487/RFC8246", + } + +@misc{rfc8247, + author="Y. Nir and T. Kivinen and P. Wouters and D. Migault", + title="{Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 8247 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8247", + pages="1--19", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8247.txt", + key="RFC 8247", + abstract={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).}, + keywords="IPsec, IKE, internet key exchange", + doi="10.17487/RFC8247", + } + +@misc{rfc8248, + author="N. Cam-Winget and L. Lorenzin", + title="{Security Automation and Continuous Monitoring (SACM) Requirements}", + howpublished="RFC 8248 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8248", + pages="1--20", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8248.txt", + key="RFC 8248", + abstract={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.}, + keywords="posture assessment, posture validation, software integrity, network authorization, software compliance", + doi="10.17487/RFC8248", + } + +@misc{rfc8249, + author="M. Zhang and X. Zhang and D. {Eastlake 3rd} and R. Perlman and S. Chatterjee", + title="{Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation}", + howpublished="RFC 8249 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8249", + pages="1--15", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8249.txt", + key="RFC 8249", + abstract={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.}, + doi="10.17487/RFC8249", + } + +@misc{rfc8250, + author="N. Elkins and R. Hamilton and M. Ackermann", + title="{IPv6 Performance and Diagnostic Metrics (PDM) Destination Option}", + howpublished="RFC 8250 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8250", + pages="1--30", + year=2017, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8250.txt", + key="RFC 8250", + abstract={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.}, + doi="10.17487/RFC8250", + } + +@misc{rfc8251, + author="JM. Valin and K. Vos", + title="{Updates to the Opus Audio Codec}", + howpublished="RFC 8251 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8251", + pages="1--12", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8251.txt", + key="RFC 8251", + abstract={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.}, + doi="10.17487/RFC8251", + } + +@misc{rfc8252, + author="W. Denniss and J. Bradley", + title="{OAuth 2.0 for Native Apps}", + howpublished="RFC 8252 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8252", + pages="1--21", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8252.txt", + key="RFC 8252", + abstract={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.}, + doi="10.17487/RFC8252", + } + +@misc{rfc8253, + author="D. Lopez and O. Gonzalez de Dios and Q. Wu and D. Dhody", + title="{PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)}", + howpublished="RFC 8253 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8253", + pages="1--26", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8253.txt", + key="RFC 8253", + abstract={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. This document updates RFC 5440 in regards to the PCEP initialization phase procedures.}, + keywords="PCE, PCEP, PCEPS, security, authentication, encryption, TLS", + doi="10.17487/RFC8253", + } + +@misc{rfc8254, + author="J. Klensin and J. Hakala", + title="{Uniform Resource Name (URN) Namespace Registration Transition}", + howpublished="RFC 8254 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8254", + pages="1--9", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8254.txt", + key="RFC 8254", + abstract={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.}, + keywords="ISBN, ISSN, NBN, national bibliography number", + doi="10.17487/RFC8254", + } + +@misc{rfc8255, + author="N. Tomkinson and N. Borenstein", + title="{Multiple Language Content Type}", + howpublished="RFC 8255 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8255", + pages="1--19", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8255.txt", + key="RFC 8255", + abstract={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.}, + keywords="multiple, language, multi, lingual, content, type, email, mime", + doi="10.17487/RFC8255", + } + +@misc{rfc8256, + author="A. D'Alessandro and L. Andersson and S. Ueno and K. Arai and Y. Koike", + title="{Requirements for Hitless MPLS Path Segment Monitoring}", + howpublished="RFC 8256 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8256", + pages="1--16", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8256.txt", + key="RFC 8256", + abstract={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).}, + keywords="HPSM, MPLS, MPLS Transport Profile, mpls-tp, OAM, monitoring, Hitless Path Segment Monitoring, Path Segment Monitoring, HPSM", + doi="10.17487/RFC8256", + } + +@misc{rfc8257, + author="S. Bensley and D. Thaler and P. Balasubramanian and L. Eggert and G. Judd", + title="{Data Center TCP (DCTCP): TCP Congestion Control for Data Centers}", + howpublished="RFC 8257 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8257", + pages="1--17", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8257.txt", + key="RFC 8257", + abstract={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 me asures.}, + keywords="TCP, ECN, DCTCP, congestion control", + doi="10.17487/RFC8257", + } + +@misc{rfc8258, + author="D. Ceccarelli and L. Berger", + title="{Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI)}", + howpublished="RFC 8258 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8258", + pages="1--7", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8258.txt", + key="RFC 8258", + abstract={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.}, + keywords="OSPF-TE, GMPLS", + doi="10.17487/RFC8258", + } + +@misc{rfc8259, + author="T. {Bray (Ed.)}", + title="{The JavaScript Object Notation (JSON) Data Interchange Format}", + howpublished="RFC 8259 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8259", + pages="1--16", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8259.txt", + key="RFC 8259", + abstract={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 document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.}, + doi="10.17487/RFC8259", + } + +@misc{rfc8260, + author="R. Stewart and M. Tuexen and S. Loreto and R. Seggelmann", + title="{Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol}", + howpublished="RFC 8260 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8260", + pages="1--23", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8260.txt", + key="RFC 8260", + abstract={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. 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.}, + doi="10.17487/RFC8260", + } + +@misc{rfc8261, + author="M. Tuexen and R. Stewart and R. Jesup and S. Loreto", + title="{Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets}", + howpublished="RFC 8261 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8261", + pages="1--10", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8261.txt", + key="RFC 8261", + abstract={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.}, + doi="10.17487/RFC8261", + } + +@misc{rfc8262, + author="C. Holmberg and I. Sedlacek", + title="{Content-ID Header Field in the Session Initiation Protocol (SIP)}", + howpublished="RFC 8262 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8262", + pages="1--14", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8262.txt", + key="RFC 8262", + abstract={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. This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.}, + keywords="SIP", + doi="10.17487/RFC8262", + } + +@misc{rfc8263, + author="B. Weis and U. Mangla and T. Karl and N. Maheshwari", + title="{Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message}", + howpublished="RFC 8263 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8263", + pages="1--17", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8263.txt", + key="RFC 8263", + abstract={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.}, + keywords="multicast security", + doi="10.17487/RFC8263", + } + +@misc{rfc8264, + author="P. Saint-Andre and M. Blanchet", + title="{PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols}", + howpublished="RFC 8264 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8264", + pages="1--43", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8264.txt", + key="RFC 8264", + abstract={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.}, + keywords="internationalization, i18n, Stringprep", + doi="10.17487/RFC8264", + } + +@misc{rfc8265, + author="P. Saint-Andre and A. Melnikov", + title="{Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords}", + howpublished="RFC 8265 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8265", + pages="1--26", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8265.txt", + key="RFC 8265", + abstract={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.}, + keywords="Username, Password, Unicode, Internationalization, i18n, Authentication, SASLprep", + doi="10.17487/RFC8265", + } + +@misc{rfc8266, + author="P. Saint-Andre", + title="{Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames}", + howpublished="RFC 8266 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8266", + pages="1--13", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8266.txt", + key="RFC 8266", + abstract={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.}, + keywords="nickname, SIP, SIMPLE, XMPP, MSRP, XCON, chatrooms", + doi="10.17487/RFC8266", + } + +@misc{rfc8267, + author="C. Lever", + title="{Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1}", + howpublished="RFC 8267 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8267", + pages="1--21", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8267.txt", + key="RFC 8267", + abstract={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.}, + keywords="NFS-over-RDMA", + doi="10.17487/RFC8267", + } + +@misc{rfc8268, + author="M. Baushke", + title="{More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)}", + howpublished="RFC 8268 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8268", + pages="1--8", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8268.txt", + key="RFC 8268", + abstract={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.}, + keywords="Public Key, Private Key, group14, group15, group16, group17, groupt18, 2048-bit, 3072-bit, 4096-bit, 6144-bit, 8192-bit", + doi="10.17487/RFC8268", + } + +@misc{rfc8269, + author="W. Kim and J. Lee and J. Park and D. Kwon and D. Kim", + title="{The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)}", + howpublished="RFC 8269 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8269", + pages="1--19", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8269.txt", + key="RFC 8269", + abstract={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.}, + keywords="ARIA, SRTP, DTLS-SRTP, MIKEY", + doi="10.17487/RFC8269", + } + +@misc{rfc8270, + author="L. Velvindron and M. Baushke", + title="{Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits}", + howpublished="RFC 8270 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8270", + pages="1--5", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8270.txt", + key="RFC 8270", + abstract={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.}, + keywords="SSH, DH", + doi="10.17487/RFC8270", + } + +@misc{rfc8271, + author="M. Taillon and T. {Saad (Ed.)} and R. {Gandhi (Ed.)} and Z. Ali and M. Bhatia", + title="{Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)}", + howpublished="RFC 8271 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8271", + pages="1--24", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8271.txt", + key="RFC 8271", + abstract={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.}, + keywords="Co-routed LSPs, Bypass assignment coordinate, Restore co-routing", + doi="10.17487/RFC8271", + } + +@misc{rfc8272, + author="C. Schmitt and B. Stiller and B. Trammell", + title="{TinyIPFIX for Smart Meters in Constrained Networks}", + howpublished="RFC 8272 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8272", + pages="1--30", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8272.txt", + key="RFC 8272", + abstract={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.}, + keywords="TinyIPFIX, Smart Meters, Constrained Networks", + doi="10.17487/RFC8272", + } + +@misc{rfc8273, + author="J. Brzozowski and G. Van de Velde", + title="{Unique IPv6 Prefix per Host}", + howpublished="RFC 8273 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8273", + pages="1--10", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8273.txt", + key="RFC 8273", + abstract={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.}, + doi="10.17487/RFC8273", + } + +@misc{rfc8274, + author="P. Kampanakis and M. Suzuki", + title="{Incident Object Description Exchange Format Usage Guidance}", + howpublished="RFC 8274 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8274", + pages="1--33", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8274.txt", + key="RFC 8274", + abstract={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.}, + keywords="IODEF best practices, IODEF implementation recommendations, IODEF examples, IODEF practical recommendations", + doi="10.17487/RFC8274", + } + +@misc{rfc8275, + author="J. Fields and A. Gruenbacher", + title="{Allowing Inheritable NFSv4 Access Control Entries to Override the Umask}", + howpublished="RFC 8275 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8275", + pages="1--7", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8275.txt", + key="RFC 8275", + abstract={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.}, + keywords="NFSv4", + doi="10.17487/RFC8275", + } + +@misc{rfc8276, + author="M. Naik and M. Eshel", + title="{File System Extended Attributes in NFSv4}", + howpublished="RFC 8276 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8276", + pages="1--28", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8276.txt", + key="RFC 8276", + abstract={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.}, + doi="10.17487/RFC8276", + } + +@misc{rfc8277, + author="E. Rosen", + title="{Using BGP to Bind MPLS Labels to Address Prefixes}", + howpublished="RFC 8277 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8277", + pages="1--23", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8277.txt", + key="RFC 8277", + abstract={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.}, + keywords="asynchronous, transfer, mode, AAL, syntax, adaption, layer", + doi="10.17487/RFC8277", + } + +@misc{rfc8278, + author="P. Seite and A. Yegin and S. Gundavelli", + title="{Mobile Access Gateway (MAG) Multipath Options}", + howpublished="RFC 8278 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8278", + pages="1--15", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8278.txt", + key="RFC 8278", + abstract={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.}, + keywords="Proxy Mobile IPv6 (PMIPv6), multihoming, Multiple WAN accesses", + doi="10.17487/RFC8278", + } + +@misc{rfc8279, + author="IJ. {Wijnands (Ed.)} and E. {Rosen (Ed.)} and A. Dolganow and T. Przygienda and S. Aldrin", + title="{Multicast Using Bit Index Explicit Replication (BIER)}", + howpublished="RFC 8279 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8279", + pages="1--43", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8279.txt", + key="RFC 8279", + abstract={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 st ate and the explicit tree-building protocols results in a considerable simplification.}, + keywords="Multicast", + doi="10.17487/RFC8279", + } + +@misc{rfc8280, + author="N. ten Oever and C. Cath", + title="{Research into Human Rights Protocol Considerations}", + howpublished="RFC 8280 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8280", + pages="1--81", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8280.txt", + key="RFC 8280", + abstract={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. 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.}, + keywords="human rights, IETF, protocols, guidelines, considerations, freedom of expression", + doi="10.17487/RFC8280", + } + +@misc{rfc8281, + author="E. Crabbe and I. Minei and S. Sivabalan and R. Varga", + title="{Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model}", + howpublished="RFC 8281 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8281", + pages="1--20", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8281.txt", + key="RFC 8281", + abstract={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. 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.}, + doi="10.17487/RFC8281", + } + +@misc{rfc8282, + author="E. Oki and T. Takeda and A. Farrel and F. Zhang", + title="{Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering}", + howpublished="RFC 8282 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8282", + pages="1--22", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8282.txt", + key="RFC 8282", + abstract={The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 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. 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.}, + keywords="Multi-layer, Multi-domain, Inter-domain, Traffic Engineering", + doi="10.17487/RFC8282", + } + +@misc{rfc8283, + author="A. {Farrel (Ed.)} and Q. {Zhao (Ed.)} and Z. Li and C. Zhou", + title="{An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control}", + howpublished="RFC 8283 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8283", + pages="1--25", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8283.txt", + key="RFC 8283", + abstract={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. 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). 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. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicabilit y 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. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.}, + keywords="PCE, SDN", + doi="10.17487/RFC8283", + } + +@misc{rfc8284, + author="S. Kille", + title="{Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages}", + howpublished="RFC 8284 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8284", + pages="1--6", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8284.txt", + key="RFC 8284", + abstract={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.}, + doi="10.17487/RFC8284", + } + +@misc{rfc8285, + author="D. Singer and H. Desineni and R. {Even (Ed.)}", + title="{A General Mechanism for RTP Header Extensions}", + howpublished="RFC 8285 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8285", + pages="1--25", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8285.txt", + key="RFC 8285", + abstract={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.}, + doi="10.17487/RFC8285", + } + +@misc{rfc8286, + author="J. Xia and R. Even and R. Huang and L. Deng", + title="{RTP/RTCP Extension for RTP Splicing Notification}", + howpublished="RFC 8286 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8286", + pages="1--22", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8286.txt", + key="RFC 8286", + abstract={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. 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.}, + doi="10.17487/RFC8286", + } + +@misc{rfc8287, + author="N. {Kumar (Ed.)} and C. {Pignataro (Ed.)} and G. Swallow and N. Akiya and S. Kini and M. Chen", + title="{Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes}", + howpublished="RFC 8287 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8287", + pages="1--25", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8287.txt", + key="RFC 8287", + abstract={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. 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.}, + keywords="MPLS, LSP Ping, SPRING, Segment Routing, SR", + doi="10.17487/RFC8287", + } + +@misc{rfc8288, + author="M. Nottingham", + title="{Web Linking}", + howpublished="RFC 8288 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8288", + pages="1--24", + year=2017, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8288.txt", + key="RFC 8288", + abstract={This specification defines a model for the relationships between resources on the Web (``links'') and the type of those relationships (``link relation types''). It also defines the serialisation of such links in HTTP headers with the Link header field.}, + keywords="link relation", + doi="10.17487/RFC8288", + } + +@misc{rfc8289, + author="K. Nichols and V. Jacobson and A. {McGregor (Ed.)} and J. {Iyengar (Ed.)}", + title="{Controlled Delay Active Queue Management}", + howpublished="RFC 8289 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8289", + pages="1--25", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8289.txt", + key="RFC 8289", + abstract={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.}, + keywords="CoDel, AQM, Active Queue Management", + doi="10.17487/RFC8289", + } + +@misc{rfc8290, + author="T. Hoeiland-Joergensen and P. McKenney and D. Taht and J. Gettys and E. Dumazet", + title="{The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm}", + howpublished="RFC 8290 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8290", + pages="1--25", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8290.txt", + key="RFC 8290", + abstract={This memo presents the FQ-CoDel hybrid packet scheduler and Active Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency. 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.}, + keywords="bufferbloat, aqm, fq\_codel, fq-codel", + doi="10.17487/RFC8290", + } + +@misc{rfc8291, + author="M. Thomson", + title="{Message Encryption for Web Push}", + howpublished="RFC 8291 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8291", + pages="1--13", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8291.txt", + key="RFC 8291", + abstract={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.}, + keywords="web, push, notification, http, encryption", + doi="10.17487/RFC8291", + } + +@misc{rfc8292, + author="M. Thomson and P. Beverloo", + title="{Voluntary Application Server Identification (VAPID) for Web Push}", + howpublished="RFC 8292 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8292", + pages="1--14", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8292.txt", + key="RFC 8292", + abstract={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.}, + keywords="authentication, restricted, restriction, signature", + doi="10.17487/RFC8292", + } + +@misc{rfc8293, + author="A. Ghanwani and L. Dunbar and M. McBride and V. Bannai and R. Krishnan", + title="{A Framework for Multicast in Network Virtualization over Layer 3}", + howpublished="RFC 8293 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8293", + pages="1--17", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8293.txt", + key="RFC 8293", + abstract={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.}, + keywords="NVO3, VXLAN, Geneve, NVGRE", + doi="10.17487/RFC8293", + } + +@misc{rfc8294, + author="X. Liu and Y. Qu and A. Lindem and C. Hopps and L. Berger", + title="{Common YANG Data Types for the Routing Area}", + howpublished="RFC 8294 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8294", + pages="1--43", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8294.txt", + key="RFC 8294", + abstract={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.}, + keywords="Network Management, Routing, YANG", + doi="10.17487/RFC8294", + } + +@misc{rfc8295, + author="S. Turner", + title="{EST (Enrollment over Secure Transport) Extensions}", + howpublished="RFC 8295 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8295", + pages="1--54", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8295.txt", + key="RFC 8295", + abstract={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.}, + keywords="Firmware, TAMP, Asymmetric Keys, Symmetric Keys, Product Availability List", + doi="10.17487/RFC8295", + } + +@misc{rfc8296, + author="IJ. {Wijnands (Ed.)} and E. {Rosen (Ed.)} and A. Dolganow and J. Tantsura and S. Aldrin and I. Meilik", + title="{Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks}", + howpublished="RFC 8296 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8296", + pages="1--24", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8296.txt", + key="RFC 8296", + abstract={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.}, + keywords="Multicast", + doi="10.17487/RFC8296", + } + +@misc{rfc8297, + author="K. Oku", + title="{An HTTP Status Code for Indicating Hints}", + howpublished="RFC 8297 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8297", + pages="1--7", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8297.txt", + key="RFC 8297", + abstract={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.}, + keywords="push, preload", + doi="10.17487/RFC8297", + } + +@misc{rfc8298, + author="I. Johansson and Z. Sarker", + title="{Self-Clocked Rate Adaptation for Multimedia}", + howpublished="RFC 8298 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8298", + pages="1--36", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8298.txt", + key="RFC 8298", + abstract={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.}, + keywords="Cellular Network, Congestion Control, RTP", + doi="10.17487/RFC8298", + } + +@misc{rfc8299, + author="Q. {Wu (Ed.)} and S. Litkowski and L. Tomotaki and K. Ogaki", + title="{YANG Data Model for L3VPN Service Delivery}", + howpublished="RFC 8299 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8299", + pages="1--188", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8299.txt", + key="RFC 8299", + abstract={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. 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.}, + doi="10.17487/RFC8299", + } + +@misc{rfc8300, + author="P. {Quinn (Ed.)} and U. {Elzur (Ed.)} and C. {Pignataro (Ed.)}", + title="{Network Service Header (NSH)}", + howpublished="RFC 8300 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8300", + pages="1--40", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8300.txt", + key="RFC 8300", + abstract={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).}, + keywords="Service Function Chaining, Network Service Header, SFC, NSH, Network Service Function", + doi="10.17487/RFC8300", + } + +@misc{rfc8301, + author="S. Kitterman", + title="{Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)}", + howpublished="RFC 8301 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8301", + pages="1--5", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8301.txt", + key="RFC 8301", + abstract={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.}, + keywords="email, authentication", + doi="10.17487/RFC8301", + } + +@misc{rfc8302, + author="Y. Li and D. {Eastlake 3rd} and L. Dunbar and R. Perlman and M. Umair", + title="{Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization}", + howpublished="RFC 8302 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8302", + pages="1--18", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8302.txt", + key="RFC 8302", + abstract={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.}, + keywords="proxy, RARP, duplicate address, DAD, DHCP, flooding", + doi="10.17487/RFC8302", + } + +@misc{rfc8303, + author="M. Welzl and M. Tuexen and N. Khademi", + title="{On the Usage of Transport Features Provided by IETF Transport Protocols}", + howpublished="RFC 8303 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8303", + pages="1--56", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8303.txt", + key="RFC 8303", + abstract={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.}, + doi="10.17487/RFC8303", + } + +@misc{rfc8304, + author="G. Fairhurst and T. Jones", + title="{Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)}", + howpublished="RFC 8304 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8304", + pages="1--20", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8304.txt", + key="RFC 8304", + abstract={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.}, + keywords="UDP Transport", + doi="10.17487/RFC8304", + } + +@misc{rfc8305, + author="D. Schinazi and T. Pauly", + title="{Happy Eyeballs Version 2: Better Connectivity Using Concurrency}", + howpublished="RFC 8305 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8305", + pages="1--15", + year=2017, + month=dec, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8305.txt", + key="RFC 8305", + abstract={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.}, + keywords="IPv6, IPv4, TCP, DNS, NAT64", + doi="10.17487/RFC8305", + } + +@misc{rfc8306, + author="Q. Zhao and D. {Dhody (Ed.)} and R. Palleti and D. King", + title="{Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths}", + howpublished="RFC 8306 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8306", + pages="1--43", + year=2017, + month=nov, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8306.txt", + key="RFC 8306", + abstract={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. This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. This document obsoletes RFC 6006.}, + doi="10.17487/RFC8306", + } + +@misc{rfc8307, + author="C. Bormann", + title="{Well-Known URIs for the WebSocket Protocol}", + howpublished="RFC 8307 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8307", + pages="1--3", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8307.txt", + key="RFC 8307", + abstract={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.}, + keywords="URI, Web, metadata, well-known, WebSocket, ws, wss", + doi="10.17487/RFC8307", + } + +@misc{rfc8308, + author="D. Bider", + title="{Extension Negotiation in the Secure Shell (SSH) Protocol}", + howpublished="RFC 8308 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8308", + pages="1--14", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8308.txt", + key="RFC 8308", + abstract={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.}, + keywords="ext-info, ext-info-s, ext-info-c, SSH\_MSG\_EXT\_INFO, SSH\_MSG\_NEWCOMPRESS, server-sig-algs, delay-compression, no-flow-control, elevation, delay compression, delayed compression, flow control, elevated", + doi="10.17487/RFC8308", + } + +@misc{rfc8309, + author="Q. Wu and W. Liu and A. Farrel", + title="{Service Models Explained}", + howpublished="RFC 8309 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8309", + pages="1--23", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8309.txt", + key="RFC 8309", + abstract={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. 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). 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.}, + keywords="YANG, NETCONF, RESTCONF, Data Model, SDN, Software Defined Network, Service Orchestrator", + doi="10.17487/RFC8309", + } + +@misc{rfc8310, + author="S. Dickinson and D. Gillmor and T. Reddy", + title="{Usage Profiles for DNS over TLS and DNS over DTLS}", + howpublished="RFC 8310 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8310", + pages="1--27", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8310.txt", + key="RFC 8310", + abstract={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.}, + keywords="DNS, transport", + doi="10.17487/RFC8310", + } + +@misc{rfc8311, + author="D. Black", + title="{Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation}", + howpublished="RFC 8311 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8311", + pages="1--20", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8311.txt", + key="RFC 8311", + abstract={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.}, + keywords="ECN", + doi="10.17487/RFC8311", + } + +@misc{rfc8312, + author="I. Rhee and L. Xu and S. Ha and A. Zimmermann and L. Eggert and R. Scheffenegger", + title="{CUBIC for Fast Long-Distance Networks}", + howpublished="RFC 8312 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8312", + pages="1--18", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8312.txt", + key="RFC 8312", + abstract={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.}, + doi="10.17487/RFC8312", + } + +@misc{rfc8313, + author="P. {Tarapore (Ed.)} and R. Sayko and G. Shepherd and T. {Eckert (Ed.)} and R. Krishnan", + title="{Use of Multicast across Inter-domain Peering Points}", + howpublished="RFC 8313 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8313", + pages="1--44", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8313.txt", + key="RFC 8313", + abstract={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.}, + keywords="multicast security, multicast troubleshooting, multicast routing, multicast tunneling, PIM, PIM-SSM, SSM, Source Specific Multicast, AMT, GRE, Automatic Multicast Tunneling, BGP, MBGP, M-BGP, MP-BGP, exchange, exchange point, NNI, content distribution, video streaming, anycast", + doi="10.17487/RFC8313", + } + +@misc{rfc8314, + author="K. Moore and C. Newman", + title="{Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access}", + howpublished="RFC 8314 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8314", + pages="1--26", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8314.txt", + key="RFC 8314", + abstract={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.}, + keywords="POP, IMAP, SMTP, MSP, mail submission, STARTTLS, DANE, TLSA", + doi="10.17487/RFC8314", + } + +@misc{rfc8315, + author="M. Baeuerle", + title="{Cancel-Locks in Netnews Articles}", + howpublished="RFC 8315 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8315", + pages="1--20", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8315.txt", + key="RFC 8315", + abstract={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.}, + keywords="Usenet, Netnews, Cancel-Lock", + doi="10.17487/RFC8315", + } + +@misc{rfc8316, + author="J. Nobre and L. Granville and A. Clemm and A. Gonzalez Prieto", + title="{Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations}", + howpublished="RFC 8316 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8316", + pages="1--16", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8316.txt", + key="RFC 8316", + abstract={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. This document is a product of the IRTF Network Management Research Group (NMRG). It is published for informational purposes.}, + keywords="Autonomic Networking, SLA, P2P", + doi="10.17487/RFC8316", + } + +@misc{rfc8317, + author="A. {Sajassi (Ed.)} and S. Salam and J. Drake and J. Uttaro and S. Boutros and J. Rabadan", + title="{Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)}", + howpublished="RFC 8317 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8317", + pages="1--23", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8317.txt", + key="RFC 8317", + abstract={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.}, + doi="10.17487/RFC8317", + } + +@misc{rfc8318, + author="S. Dawkins", + title="{IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee}", + howpublished="RFC 8318 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8318", + pages="1--9", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8318.txt", + key="RFC 8318", + abstract={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). This document updates RFC 7437.}, + keywords="nomcom, IAOC", + doi="10.17487/RFC8318", + } + +@misc{rfc8319, + author="S. Krishnan and J. Korhonen and S. Chakrabarti and E. Nordmark and A. Yourtchenko", + title="{Support for Adjustable Maximum Router Lifetimes per Link}", + howpublished="RFC 8319 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8319", + pages="1--7", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8319.txt", + key="RFC 8319", + abstract={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. 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.}, + doi="10.17487/RFC8319", + } + +@misc{rfc8320, + author="A. Atlas and K. Tiruveedhula and C. Bowers and J. Tantsura and IJ. Wijnands", + title="{LDP Extensions to Support Maximally Redundant Trees}", + howpublished="RFC 8320 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8320", + pages="1--21", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8320.txt", + key="RFC 8320", + abstract={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''. 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. MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.}, + keywords="fast-reroute, MRT, MRT-FRR", + doi="10.17487/RFC8320", + } + +@misc{rfc8321, + author="G. {Fioccola (Ed.)} and A. Capello and M. Cociglio and L. Castaldelli and M. Chen and L. Zheng and G. Mirsky and T. Mizrahi", + title="{Alternate-Marking Method for Passive and Hybrid Performance Monitoring}", + howpublished="RFC 8321 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8321", + pages="1--33", + year=2018, + month=jan, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8321.txt", + key="RFC 8321", + abstract={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.}, + keywords="Alternate Marking, Marking Method, Coloring Technique", + doi="10.17487/RFC8321", + } + +@misc{rfc8322, + author="J. Field and S. Banghart and D. Waltermire", + title="{Resource-Oriented Lightweight Information Exchange (ROLIE)}", + howpublished="RFC 8322 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8322", + pages="1--43", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8322.txt", + key="RFC 8322", + abstract={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.}, + keywords="syndication, atom, atom publishing protocol, atom syndication format, rest, information sharing, security automation", + doi="10.17487/RFC8322", + } + +@misc{rfc8323, + author="C. Bormann and S. Lemay and H. Tschofenig and K. Hartke and B. Silverajan and B. {Raymor (Ed.)}", + title="{CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets}", + howpublished="RFC 8323 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8323", + pages="1--54", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8323.txt", + key="RFC 8323", + abstract={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. 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.}, + keywords="CoAP, Constrained Application Protocol, REST, IoT, Internet of Things, NAT Traversal, CoAP in Browsers", + doi="10.17487/RFC8323", + } + +@misc{rfc8324, + author="J. Klensin", + title="{DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?}", + howpublished="RFC 8324 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8324", + pages="1--29", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8324.txt", + key="RFC 8324", + abstract={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.}, + keywords="domain name, DNS functions, DNS extensions", + doi="10.17487/RFC8324", + } + +@misc{rfc8325, + author="T. Szigeti and J. Henry and F. Baker", + title="{Mapping Diffserv to IEEE 802.11}", + howpublished="RFC 8325 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8325", + pages="1--37", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8325.txt", + key="RFC 8325", + abstract={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.}, + keywords="quality of service, QoS, QoS classes, mapping, DSCP, Diffserv, Access Category, AC, User Priority, UP, 802.11, Wi-Fi", + doi="10.17487/RFC8325", + } + +@misc{rfc8326, + author="P. {Francois (Ed.)} and B. {Decraene (Ed.)} and C. Pelsser and K. Patel and C. Filsfils", + title="{Graceful BGP Session Shutdown}", + howpublished="RFC 8326 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8326", + pages="1--12", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8326.txt", + key="RFC 8326", + abstract={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.}, + doi="10.17487/RFC8326", + } + +@misc{rfc8327, + author="W. Hargrave and M. Griswold and J. Snijders and N. Hilliard", + title="{Mitigating the Negative Impact of Maintenance through BGP Session Culling}", + howpublished="RFC 8327 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8327", + pages="1--10", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8327.txt", + key="RFC 8327", + abstract={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.}, + keywords="BGP, culling, EBGP, sessions", + doi="10.17487/RFC8327", + } + +@misc{rfc8328, + author="W. Liu and C. Xie and J. Strassner and G. Karagiannis and M. Klyus and J. Bi and Y. Cheng and D. Zhang", + title="{Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)}", + howpublished="RFC 8328 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8328", + pages="1--15", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8328.txt", + key="RFC 8328", + abstract={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.}, + keywords="Information models, YANG data models, Event Condition Action, policy rules, GPIM, EPRIM, declarative policy, intent-based policy", + doi="10.17487/RFC8328", + } + +@misc{rfc8329, + author="D. Lopez and E. Lopez and L. Dunbar and J. Strassner and R. Kumar", + title="{Framework for Interface to Network Security Functions}", + howpublished="RFC 8329 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8329", + pages="1--25", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8329.txt", + key="RFC 8329", + abstract={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.}, + keywords="security policy, security capability", + doi="10.17487/RFC8329", + } + +@misc{rfc8330, + author="H. Long and M. Ye and G. Mirsky and A. D'Alessandro and H. Shah", + title="{OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth}", + howpublished="RFC 8330 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8330", + pages="1--10", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8330.txt", + key="RFC 8330", + abstract={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 des cribe specific uses.}, + keywords="microwave, copper, Generalized SCSI-TLV", + doi="10.17487/RFC8330", + } + +@misc{rfc8331, + author="T. Edwards", + title="{RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data}", + howpublished="RFC 8331 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8331", + pages="1--20", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8331.txt", + key="RFC 8331", + abstract={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).}, + keywords="SDI, video, captions, timecode, ANC", + doi="10.17487/RFC8331", + } + +@misc{rfc8332, + author="D. Bider", + title="{Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol}", + howpublished="RFC 8332 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8332", + pages="1--9", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8332.txt", + key="RFC 8332", + abstract={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.}, + keywords="rsa-sha2-256, rsa-sha2-512, ssh-rsa, publickey, server-sig-algs, signature, authentication", + doi="10.17487/RFC8332", + } + +@misc{rfc8333, + author="S. Litkowski and B. Decraene and C. Filsfils and P. Francois", + title="{Micro-loop Prevention by Introducing a Local Convergence Delay}", + howpublished="RFC 8333 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8333", + pages="1--26", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8333.txt", + key="RFC 8333", + abstract={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. 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. The mechanism is limited to the link-down event in order to keep the mechanism simple. Simulations using real network topologies have been performed and show that local loops are a significant portion (>50\%) of the total forwarding loops.}, + doi="10.17487/RFC8333", + } + +@misc{rfc8334, + author="J. Gould and W. Tan and G. Brown", + title="{Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)}", + howpublished="RFC 8334 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8334", + pages="1--58", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8334.txt", + key="RFC 8334", + abstract={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.}, + keywords="EPP, Sunrise, Landrush, Trademark Clearinghouse, Trademark Claims, domain name registry, launch phase", + doi="10.17487/RFC8334", + } + +@misc{rfc8335, + author="R. Bonica and R. Thomas and J. Linkova and C. Lenart and M. Boucadair", + title="{PROBE: A Utility for Probing Interfaces}", + howpublished="RFC 8335 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8335", + pages="1--19", + year=2018, + month=feb, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8335.txt", + key="RFC 8335", + abstract={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.}, + keywords="Ping, ICMP", + doi="10.17487/RFC8335", + } + +@misc{rfc8336, + author="M. Nottingham and E. Nygren", + title="{The ORIGIN HTTP/2 Frame}", + howpublished="RFC 8336 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8336", + pages="1--11", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8336.txt", + key="RFC 8336", + abstract={This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.}, + keywords="connection coalescing, HTTP", + doi="10.17487/RFC8336", + } + +@misc{rfc8337, + author="M. Mathis and A. Morton", + title="{Model-Based Metrics for Bulk Transport Capacity}", + howpublished="RFC 8337 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8337", + pages="1--55", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8337.txt", + key="RFC 8337", + abstract={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. 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. 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 t he 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.}, + keywords="performance, bulk capacity, BTC, diagnostic, statistics", + doi="10.17487/RFC8337", + } + +@misc{rfc8338, + author="S. {Boutros (Ed.)} and S. {Sivabalan (Ed.)}", + title="{Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP}", + howpublished="RFC 8338 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8338", + pages="1--20", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8338.txt", + key="RFC 8338", + abstract={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.}, + doi="10.17487/RFC8338", + } + +@misc{rfc8339, + author="P. {Jain (Ed.)} and S. Boutros and S. Aldrin", + title="{Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms}", + howpublished="RFC 8339 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8339", + pages="1--10", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8339.txt", + key="RFC 8339", + abstract={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.}, + doi="10.17487/RFC8339", + } + +@misc{rfc8340, + author="M. Bjorklund and L. {Berger (Ed.)}", + title="{YANG Tree Diagrams}", + howpublished="RFC 8340 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8340", + pages="1--13", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8340.txt", + key="RFC 8340", + abstract={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.}, + doi="10.17487/RFC8340", + } + +@misc{rfc8341, + author="A. Bierman and M. Bjorklund", + title="{Network Configuration Access Control Model}", + howpublished="RFC 8341 (Internet Standard)", + series="Internet Request for Comments", + type="RFC", + number="8341", + pages="1--58", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8341.txt", + key="RFC 8341", + abstract={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. This document obsoletes RFC 6536.}, + keywords="NETCONF RESTCONF, YANG, XML", + doi="10.17487/RFC8341", + } + +@misc{rfc8342, + author="M. Bjorklund and J. Schoenwaelder and P. Shafer and K. Watsen and R. Wilton", + title="{Network Management Datastore Architecture (NMDA)}", + howpublished="RFC 8342 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8342", + pages="1--44", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8342.txt", + key="RFC 8342", + abstract={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.}, + keywords="YANG, NETCONF, RESTCONF, Network Management", + doi="10.17487/RFC8342", + } + +@misc{rfc8343, + author="M. Bjorklund", + title="{A YANG Data Model for Interface Management}", + howpublished="RFC 8343 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8343", + pages="1--49", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8343.txt", + key="RFC 8343", + abstract={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). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223.}, + doi="10.17487/RFC8343", + } + +@misc{rfc8344, + author="M. Bjorklund", + title="{A YANG Data Model for IP Management}", + howpublished="RFC 8344 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8344", + pages="1--34", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8344.txt", + key="RFC 8344", + abstract={This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document obsoletes RFC 7277.}, + doi="10.17487/RFC8344", + } + +@misc{rfc8345, + author="A. Clemm and J. Medved and R. Varga and N. Bahadur and H. Ananthakrishnan and X. Liu", + title="{A YANG Data Model for Network Topologies}", + howpublished="RFC 8345 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8345", + pages="1--57", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8345.txt", + key="RFC 8345", + abstract={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.}, + keywords="topology", + doi="10.17487/RFC8345", + } + +@misc{rfc8346, + author="A. Clemm and J. Medved and R. Varga and X. Liu and H. Ananthakrishnan and N. Bahadur", + title="{A YANG Data Model for Layer 3 Topologies}", + howpublished="RFC 8346 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8346", + pages="1--35", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8346.txt", + key="RFC 8346", + abstract={This document defines a YANG data model for Layer 3 network topologies.}, + keywords="topology", + doi="10.17487/RFC8346", + } + +@misc{rfc8347, + author="X. {Liu (Ed.)} and A. Kyparlis and R. Parikh and A. Lindem and M. Zhang", + title="{A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)}", + howpublished="RFC 8347 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8347", + pages="1--45", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8347.txt", + key="RFC 8347", + abstract={This document describes a data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered.}, + keywords="Network Management, Routing, YANG", + doi="10.17487/RFC8347", + } + +@misc{rfc8348, + author="A. Bierman and M. Bjorklund and J. Dong and D. Romascanu", + title="{A YANG Data Model for Hardware Management}", + howpublished="RFC 8348 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8348", + pages="1--60", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8348.txt", + key="RFC 8348", + abstract={This document defines a YANG data model for the management of hardware on a single server.}, + keywords="ENTITY-MIB", + doi="10.17487/RFC8348", + } + +@misc{rfc8349, + author="L. Lhotka and A. Lindem and Y. Qu", + title="{A YANG Data Model for Routing Management (NMDA Version)}", + howpublished="RFC 8349 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8349", + pages="1--80", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8349.txt", + key="RFC 8349", + abstract={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. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.}, + keywords="configuration, IPv6 Router Advertisements, NETCONF, RESTCONF", + doi="10.17487/RFC8349", + } + +@misc{rfc8350, + author="R. Zhang and R. Pazhyannur and S. Gundavelli and Z. Cao and H. Deng and Z. Du", + title="{Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)}", + howpublished="RFC 8350 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8350", + pages="1--29", + year=2018, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8350.txt", + key="RFC 8350", + abstract={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.}, + keywords="Wi-Fi, WLAN, PMIP, GRE", + doi="10.17487/RFC8350", + } + +@misc{rfc8351, + author="S. Leonard", + title="{The PKCS \#8 EncryptedPrivateKeyInfo Media Type}", + howpublished="RFC 8351 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8351", + pages="1--7", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8351.txt", + key="RFC 8351", + abstract={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.}, + doi="10.17487/RFC8351", + } + +@misc{rfc8352, + author="C. Gomez and M. Kovatsch and H. Tian and Z. {Cao (Ed.)}", + title="{Energy-Efficient Features of Internet of Things Protocols}", + howpublished="RFC 8352 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8352", + pages="1--24", + year=2018, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8352.txt", + key="RFC 8352", + abstract={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.}, + keywords="IoT, Radio Duty Cycling, 6LoWPAN, 6Lo, CoAP, RPL", + doi="10.17487/RFC8352", + } + +@misc{rfc8353, + author="M. Upadhyay and S. Malkani and W. Wang", + title="{Generic Security Service API Version 2: Java Bindings Update}", + howpublished="RFC 8353 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8353", + pages="1--96", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8353.txt", + key="RFC 8353", + abstract={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. 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, an d 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).}, + keywords="JGSS, GSS-API", + doi="10.17487/RFC8353", + } + +@misc{rfc8354, + author="J. Brzozowski and J. Leddy and C. Filsfils and R. {Maglione (Ed.)} and M. Townsley", + title="{Use Cases for IPv6 Source Packet Routing in Networking (SPRING)}", + howpublished="RFC 8354 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8354", + pages="1--9", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8354.txt", + key="RFC 8354", + abstract={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.}, + doi="10.17487/RFC8354", + } + +@misc{rfc8355, + author="C. {Filsfils (Ed.)} and S. {Previdi (Ed.)} and B. Decraene and R. Shakir", + title="{Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks}", + howpublished="RFC 8355 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8355", + pages="1--13", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8355.txt", + key="RFC 8355", + abstract={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.}, + keywords="SEGMENT ROUTING, RESILIENCY, PROTECTION, CONVERGENCE", + doi="10.17487/RFC8355", + } + +@misc{rfc8356, + author="D. Dhody and D. King and A. Farrel", + title="{Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)}", + howpublished="RFC 8356 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8356", + pages="1--7", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8356.txt", + key="RFC 8356", + abstract={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. 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.}, + keywords="PCE, PCEP, IANA, Experimental", + doi="10.17487/RFC8356", + } + +@misc{rfc8357, + author="N. Shen and E. Chen", + title="{Generalized UDP Source Port for DHCP Relay}", + howpublished="RFC 8357 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8357", + pages="1--10", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8357.txt", + key="RFC 8357", + abstract={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.}, + doi="10.17487/RFC8357", + } + +@misc{rfc8358, + author="R. Housley", + title="{Update to Digital Signatures on Internet-Draft Documents}", + howpublished="RFC 8358 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8358", + pages="1--9", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8358.txt", + key="RFC 8358", + abstract={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. 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. This document updates RFC 5485.}, + keywords="cms, cryptographic message syntax, detached signature", + doi="10.17487/RFC8358", + } + +@misc{rfc8359, + author="X. {Zhang (Ed.)} and V. {Beeram (Ed.)} and I. Bryskin and D. Ceccarelli and O. Gonzalez de Dios", + title="{Network-Assigned Upstream Label}", + howpublished="RFC 8359 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8359", + pages="1--10", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8359.txt", + key="RFC 8359", + abstract={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.}, + doi="10.17487/RFC8359", + } + +@misc{rfc8360, + author="G. Huston and G. Michaelson and C. Martinez and T. Bruijnzeels and A. Newton and D. Shaw", + title="{Resource Public Key Infrastructure (RPKI) Validation Reconsidered}", + howpublished="RFC 8360 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8360", + pages="1--29", + year=2018, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8360.txt", + key="RFC 8360", + abstract={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. 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. 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. 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. Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.}, + doi="10.17487/RFC8360", + } + +@misc{rfc8361, + author="W. Hao and Y. Li and M. Durrani and S. Gupta and A. Qu", + title="{Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic}", + howpublished="RFC 8361 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8361", + pages="1--17", + year=2018, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8361.txt", + key="RFC 8361", + abstract={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 t he actual ingress RBridge. This document updates RFC 6325.}, + keywords="TRILL, RBridge, CMT, LAALP", + doi="10.17487/RFC8361", + } + +@misc{rfc8362, + author="A. Lindem and A. Roy and D. Goethals and V. Reddy Vallem and F. Baker", + title="{OSPFv3 Link State Advertisement (LSA) Extensibility}", + howpublished="RFC 8362 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8362", + pages="1--33", + year=2018, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8362.txt", + key="RFC 8362", + abstract={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. 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.}, + doi="10.17487/RFC8362", + } + +@misc{rfc8363, + author="X. Zhang and H. Zheng and R. Casellas and O. Gonzalez de Dios and D. Ceccarelli", + title="{GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks}", + howpublished="RFC 8363 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8363", + pages="1--17", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8363.txt", + key="RFC 8363", + abstract={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''. 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.}, + keywords="flexi-grid, OSPF-TE, central frequency, frequency slot, channel spacing", + doi="10.17487/RFC8363", + } + +@misc{rfc8364, + author="IJ. Wijnands and S. Venaas and M. Brig and A. Jonasson", + title="{PIM Flooding Mechanism (PFM) and Source Discovery (SD)}", + howpublished="RFC 8364 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8364", + pages="1--18", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8364.txt", + key="RFC 8364", + abstract={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.}, + keywords="Multicast", + doi="10.17487/RFC8364", + } + +@misc{rfc8365, + author="A. {Sajassi (Ed.)} and J. {Drake (Ed.)} and N. Bitar and R. Shekhar and J. Uttaro and W. Henderickx", + title="{A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)}", + howpublished="RFC 8365 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8365", + pages="1--33", + year=2018, + month=mar, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8365.txt", + key="RFC 8365", + abstract={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.}, + keywords="EVPN Control Plane with VxLAN Encapsulation, EVPN Control Plane with NvGRE Encapsulation", + doi="10.17487/RFC8365", + } + +@misc{rfc8366, + author="K. Watsen and M. Richardson and M. Pritikin and T. Eckert", + title="{A Voucher Artifact for Bootstrapping Protocols}", + howpublished="RFC 8366 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8366", + pages="1--23", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8366.txt", + key="RFC 8366", + abstract={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''. 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)). This document only defines the voucher artifact, leaving it to other +documents to describe specialized protocols for accessing it.}, + keywords="voucher", + doi="10.17487/RFC8366", + } + +@misc{rfc8367, + author="T. Mizrahi and J. Yallouz", + title="{Wrongful Termination of Internet Protocol (IP) Packets}", + howpublished="RFC 8367 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8367", + pages="1--6", + year=2018, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8367.txt", + key="RFC 8367", + abstract={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.}, + doi="10.17487/RFC8367", + } + +@misc{rfc8368, + author="T. {Eckert (Ed.)} and M. Behringer", + title="{Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)}", + howpublished="RFC 8368 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8368", + pages="1--24", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8368.txt", + key="RFC 8368", + abstract={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. 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. 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.}, + doi="10.17487/RFC8368", + } + +@misc{rfc8369, + author="H. Kaplan", + title="{Internationalizing IPv6 Using 128-Bit Unicode}", + howpublished="RFC 8369 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8369", + pages="1--11", + year=2018, + month=apr, + day="1", +issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8369.txt", + key="RFC 8369", + abstract={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.}, + doi="10.17487/RFC8369", + } + +@misc{rfc8370, + author="V. {Beeram (Ed.)} and I. Minei and R. Shakir and D. Pacella and T. Saad", + title="{Techniques to Improve the Scalability of RSVP-TE Deployments}", + howpublished="RFC 8370 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8370", + pages="1--11", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8370.txt", + key="RFC 8370", + abstract={Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed. 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.}, + keywords="RSVP-TE Scaling, RI-RSVP, Per-Peer Flow Control", + doi="10.17487/RFC8370", + } + +@misc{rfc8371, + author="C. Perkins and V. Devarapalli", + title="{Mobile Node Identifier Types for MIPv6}", + howpublished="RFC 8371 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8371", + pages="1--16", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8371.txt", + key="RFC 8371", + abstract={This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283.}, + keywords="Mobility, IPv6, Authentication", + doi="10.17487/RFC8371", + } + +@misc{rfc8372, + author="S. Bryant and C. Pignataro and M. Chen and Z. Li and G. Mirsky", + title="{MPLS Flow Identification Considerations}", + howpublished="RFC 8372 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8372", + pages="1--11", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8372.txt", + key="RFC 8372", + abstract={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.}, + keywords="OAM, performance monitoring, flow identification", + doi="10.17487/RFC8372", + } + +@misc{rfc8373, + author="R. Gellens", + title="{Negotiating Human Language in Real-Time Communications}", + howpublished="RFC 8373 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8373", + pages="1--13", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8373.txt", + key="RFC 8373", + abstract={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). This document describes the need as well as a solution that uses new SDP media attributes.}, + keywords="SDP, language, human language, SIP, SLIM", + doi="10.17487/RFC8373", + } + +@misc{rfc8374, + author="K. {Sriram (Ed.)}", + title="{BGPsec Design Choices and Summary of Supporting Discussions}", + howpublished="RFC 8374 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8374", + pages="1--50", + year=2018, + month=apr, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8374.txt", + key="RFC 8374", + abstract={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.}, + keywords="Internet Routing Security", + doi="10.17487/RFC8374", + } + +@misc{rfc8375, + author="P. Pfister and T. Lemon", + title="{Special-Use Domain 'home.arpa.'}", + howpublished="RFC 8375 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8375", + pages="1--12", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8375.txt", + key="RFC 8375", + abstract={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'.}, + keywords="Homenet, TLD, RFC6761, .home.arpa", + doi="10.17487/RFC8375", + } + +@misc{rfc8376, + author="S. {Farrell (Ed.)}", + title="{Low-Power Wide Area Network (LPWAN) Overview}", + howpublished="RFC 8376 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8376", + pages="1--43", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8376.txt", + key="RFC 8376", + abstract={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.}, + keywords="Low Power Wide Area Network Overview", + doi="10.17487/RFC8376", + } + +@misc{rfc8377, + author="D. {Eastlake 3rd} and M. Zhang and A. Banerjee", + title="{Transparent Interconnection of Lots of Links (TRILL): Multi-Topology}", + howpublished="RFC 8377 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8377", + pages="1--20", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8377.txt", + key="RFC 8377", + abstract={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.}, + doi="10.17487/RFC8377", + } + +@misc{rfc8378, + author="V. Moreno and D. Farinacci", + title="{Signal-Free Locator/ID Separation Protocol (LISP) Multicast}", + howpublished="RFC 8378 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8378", + pages="1--21", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8378.txt", + key="RFC 8378", + abstract={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.}, + keywords="LISP, deployment", + doi="10.17487/RFC8378", + } + +@misc{rfc8379, + author="S. Hegde and P. Sarkar and H. Gredler and M. Nanduri and L. Jalil", + title="{OSPF Graceful Link Shutdown}", + howpublished="RFC 8379 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8379", + pages="1--17", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8379.txt", + key="RFC 8379", + abstract={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. 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. This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.}, + keywords="MPLS, IGP, OSPF", + doi="10.17487/RFC8379", + } + +@misc{rfc8380, + author="L. Dunbar and D. {Eastlake 3rd} and R. Perlman", + title="{Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation}", + howpublished="RFC 8380 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8380", + pages="1--10", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8380.txt", + key="RFC 8380", + abstract={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.}, + keywords="Directory, Nickname", + doi="10.17487/RFC8380", + } + +@misc{rfc8381, + author="D. {Eastlake 3rd} and Y. Li and W. Hao and A. Banerjee", + title="{Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol}", + howpublished="RFC 8381 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8381", + pages="1--11", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8381.txt", + key="RFC 8381", + abstract={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.}, + keywords="OUI, CID", + doi="10.17487/RFC8381", + } + +@misc{rfc8382, + author="D. {Hayes (Ed.)} and S. Ferlin and M. Welzl and K. Hiorth", + title="{Shared Bottleneck Detection for Coupled Congestion Control for RTP Media}", + howpublished="RFC 8382 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8382", + pages="1--25", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8382.txt", + key="RFC 8382", + abstract={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.}, + keywords="SBD", + doi="10.17487/RFC8382", + } + +@misc{rfc8383, + author="W. Hao and D. {Eastlake 3rd} and Y. Li and M. Umair", + title="{Transparent Interconnection of Lots of Links (TRILL): Address Flush Message}", + howpublished="RFC 8383 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8383", + pages="1--20", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8383.txt", + key="RFC 8383", + abstract={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. 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.}, + keywords="convergence, VLAN, data label, FGL", + doi="10.17487/RFC8383", + } + +@misc{rfc8384, + author="R. Perlman and F. Hu and D. {Eastlake 3rd} and T. Liao", + title="{Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes}", + howpublished="RFC 8384 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8384", + pages="1--17", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8384.txt", + key="RFC 8384", + abstract={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.}, + keywords="TRILL, Smart Endnode", + doi="10.17487/RFC8384", + } + +@misc{rfc8385, + author="M. Umair and S. Kingston Smiler and D. {Eastlake 3rd} and L. Yong", + title="{Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS}", + howpublished="RFC 8385 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8385", + pages="1--16", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8385.txt", + key="RFC 8385", + abstract={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.}, + keywords="VPLS, VPTS, TIR", + doi="10.17487/RFC8385", + } + +@misc{rfc8386, + author="R. Winter and M. Faath and F. Weisshaar", + title="{Privacy Considerations for Protocols Relying on IP Broadcast or Multicast}", + howpublished="RFC 8386 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8386", + pages="1--13", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8386.txt", + key="RFC 8386", + abstract={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.}, + keywords="IP broadcasts, multicast, privacy considerations", + doi="10.17487/RFC8386", + } + +@misc{rfc8387, + author="M. Sethi and J. Arkko and A. Keranen and H. Back", + title="{Practical Considerations and Implementation Experiences in Securing Smart Object Networks}", + howpublished="RFC 8387 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8387", + pages="1--33", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8387.txt", + key="RFC 8387", + abstract={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.}, + keywords="IoT, security, integrity, signing, ECC, CoAP, asymmetric, cryptography", + doi="10.17487/RFC8387", + } + +@misc{rfc8388, + author="J. {Rabadan (Ed.)} and S. Palislamovic and W. Henderickx and A. Sajassi and J. Uttaro", + title="{Usage and Applicability of BGP MPLS-Based Ethernet VPN}", + howpublished="RFC 8388 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8388", + pages="1--31", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8388.txt", + key="RFC 8388", + abstract={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.}, + keywords="EVPN", + doi="10.17487/RFC8388", + } + +@misc{rfc8390, + author="Z. {Ali (Ed.)} and G. {Swallow (Ed.)} and F. {Zhang (Ed.)} and D. {Beller (Ed.)}", + title="{RSVP-TE Path Diversity Using Exclude Route}", + howpublished="RFC 8390 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8390", + pages="1--26", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8390.txt", + key="RFC 8390", + abstract={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). 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 ex ist 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.}, + keywords="LSP diversity", + doi="10.17487/RFC8390", + } + +@misc{rfc8391, + author="A. Huelsing and D. Butin and S. Gazdag and J. Rijneveld and A. Mohaisen", + title="{XMSS: eXtended Merkle Signature Scheme}", + howpublished="RFC 8391 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8391", + pages="1--74", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8391.txt", + key="RFC 8391", + abstract={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.}, + keywords="Digital signature, cryptography, post-quantum cryptography, Hash-based signatures, Merkle signatures, Merkle tree, hash function, Winternitz, Winternitz one-time signature scheme, WOTS, W-OTS, WOTS+, W-OTS+, XMSS-MT, multi-tree XMSS", + doi="10.17487/RFC8391", + } + +@misc{rfc8392, + author="M. Jones and E. Wahlstroem and S. Erdtman and H. Tschofenig", + title="{CBOR Web Token (CWT)}", + howpublished="RFC 8392 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8392", + pages="1--25", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8392.txt", + key="RFC 8392", + abstract={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.}, + keywords="JSON Web Token, JWT, Claims, Concise Binary Object Representation, CBOR, CBOR Object Signing and Encryption, COSE, OAuth, ACE", + doi="10.17487/RFC8392", + } + +@misc{rfc8393, + author="A. Farrel and J. Drake", + title="{Operating the Network Service Header (NSH) with Next Protocol ``None''}", + howpublished="RFC 8393 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8393", + pages="1--12", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8393.txt", + key="RFC 8393", + abstract={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''. 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.}, + keywords="Service Function Chaining, Network Service Header, Metadata", + doi="10.17487/RFC8393", + } + +@misc{rfc8394, + author="Y. Li and D. {Eastlake 3rd} and L. Kreeger and T. Narten and D. Black", + title="{Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements}", + howpublished="RFC 8394 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8394", + pages="1--26", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8394.txt", + key="RFC 8394", + abstract={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. 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.}, + keywords="NVO3, VDP", + doi="10.17487/RFC8394", + } + +@misc{rfc8395, + author="K. Patel and S. Boutros and J. Liste and B. Wen and J. Rabadan", + title="{Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels}", + howpublished="RFC 8395 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8395", + pages="1--9", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8395.txt", + key="RFC 8395", + abstract={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.}, + doi="10.17487/RFC8395", + } + +@misc{rfc8396, + author="J. Peterson and T. McGarry", + title="{Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework}", + howpublished="RFC 8396 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8396", + pages="1--23", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8396.txt", + key="RFC 8396", + abstract={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.}, + keywords="SIP, Problem Statement, Real-Time Communication", + doi="10.17487/RFC8396", + } + +@misc{rfc8397, + author="M. Zhang and D. {Eastlake 3rd} and R. Perlman and H. Zhai and D. Liu", + title="{Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames}", + howpublished="RFC 8397 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8397", + pages="1--16", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8397.txt", + key="RFC 8397", + abstract={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.}, + keywords="Aggregated, Global Tree, Local Tree", + doi="10.17487/RFC8397", + } + +@misc{rfc8398, + author="A. {Melnikov (Ed.)} and W. {Chuang (Ed.)}", + title="{Internationalized Email Addresses in X.509 Certificates}", + howpublished="RFC 8398 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8398", + pages="1--12", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8398.txt", + key="RFC 8398", + abstract={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. This document updates RFC 5280.}, + keywords="EAI, PKIX, emal address", + doi="10.17487/RFC8398", + } + +@misc{rfc8399, + author="R. Housley", + title="{Internationalization Updates to RFC 5280}", + howpublished="RFC 8399 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8399", + pages="1--9", + year=2018, + month=may, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8399.txt", + key="RFC 8399", + abstract={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.}, + doi="10.17487/RFC8399", + } + +@misc{rfc8400, + author="H. Chen and A. Liu and T. Saad and F. Xu and L. Huang", + title="{Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection}", + howpublished="RFC 8400 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8400", + pages="1--21", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8400.txt", + key="RFC 8400", + abstract={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).}, + keywords="FRR, Fast Reroute", + doi="10.17487/RFC8400", + } + +@misc{rfc8401, + author="L. {Ginsberg (Ed.)} and T. Przygienda and S. Aldrin and Z. Zhang", + title="{Bit Index Explicit Replication (BIER) Support via IS-IS}", + howpublished="RFC 8401 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8401", + pages="1--12", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8401.txt", + key="RFC 8401", + abstract={This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.}, + doi="10.17487/RFC8401", + } + +@misc{rfc8402, + author="C. {Filsfils (Ed.)} and S. {Previdi (Ed.)} and L. Ginsberg and B. Decraene and S. Litkowski and R. Shakir", + title="{Segment Routing Architecture}", + howpublished="RFC 8402 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8402", + pages="1--32", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8402.txt", + key="RFC 8402", + abstract={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. 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. 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 t he 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.}, + doi="10.17487/RFC8402", + } + +@misc{rfc8403, + author="R. {Geib (Ed.)} and C. Filsfils and C. {Pignataro (Ed.)} and N. Kumar", + title="{A Scalable and Topology-Aware MPLS Data-Plane Monitoring System}", + howpublished="RFC 8403 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8403", + pages="1--19", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8403.txt", + key="RFC 8403", + abstract={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.}, + keywords="Segment based Routing, OAM, LSP surveillance, MPLS monitoring", + doi="10.17487/RFC8403", + } + +@misc{rfc8404, + author="K. {Moriarty (Ed.)} and A. {Morton (Ed.)}", + title="{Effects of Pervasive Encryption on Operators}", + howpublished="RFC 8404 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8404", + pages="1--53", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8404.txt", + key="RFC 8404", + abstract={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.}, + keywords="NETCONF, RESTCONF, Monitoring, Management, Security Management, Operations", + doi="10.17487/RFC8404", + } + +@misc{rfc8405, + author="B. Decraene and S. Litkowski and H. Gredler and A. Lindem and P. Francois and C. Bowers", + title="{Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs}", + howpublished="RFC 8405 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8405", + pages="1--14", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8405.txt", + key="RFC 8405", + abstract={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. 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.}, + doi="10.17487/RFC8405", + } + +@misc{rfc8406, + author="B. Adamson and C. Adjih and J. Bilbao and V. Firoiu and F. Fitzek and S. Ghanem and E. Lochin and A. Masucci and M-J. Montpetit and M. Pedersen and G. Peralta and V. {Roca (Ed.)} and P. Saxena and S. Sivakumar", + title="{Taxonomy of Coding Techniques for Efficient Network Communications}", + howpublished="RFC 8406 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8406", + pages="1--15", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8406.txt", + key="RFC 8406", + abstract={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.}, + keywords="Network Coding, Taxonomy", + doi="10.17487/RFC8406", + } + +@misc{rfc8408, + author="S. Sivabalan and J. Tantsura and I. Minei and R. Varga and J. Hardwick", + title="{Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages}", + howpublished="RFC 8408 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8408", + pages="1--12", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8408.txt", + key="RFC 8408", + abstract={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.}, + doi="10.17487/RFC8408", + } + +@misc{rfc8409, + author="I. {Young (Ed.)} and L. Johansson and S. Cantor", + title="{The Entity Category Security Assertion Markup Language (SAML) Attribute Types}", + howpublished="RFC 8409 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8409", + pages="1--12", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8409.txt", + key="RFC 8409", + abstract={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. This document is a product of the working group process of the Research and Education FEDerations (REFEDS) group.}, + keywords="REFEDS", + doi="10.17487/RFC8409", + } + +@misc{rfc8410, + author="S. Josefsson and J. Schaad", + title="{Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure}", + howpublished="RFC 8410 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8410", + pages="1--20", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8410.txt", + key="RFC 8410", + abstract={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.}, + keywords="Elliptic Curve Cryptography, Curve25519, Curve448, Goldilocks, X.509, PKIX, PKI, OID, ASN.1, EdDSA, Ed25519, Ed448, X25519, X448", + doi="10.17487/RFC8410", + } + +@misc{rfc8411, + author="J. Schaad and R. Andrews", + title="{IANA Registration for the Cryptographic Algorithm Object Identifier Range}", + howpublished="RFC 8411 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8411", + pages="1--5", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8411.txt", + key="RFC 8411", + abstract={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.}, + doi="10.17487/RFC8411", + } + +@misc{rfc8412, + author="C. Schmidt and D. Haynes and C. Coffin and D. Waltermire and J. Fitzgerald-McKay", + title="{Software Inventory Message and Attributes (SWIMA) for PA-TNC}", + howpublished="RFC 8412 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8412", + pages="1--101", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8412.txt", + key="RFC 8412", + abstract={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).}, + keywords="SWID, PA-TNC, NEA, Software inventory", + doi="10.17487/RFC8412", + } + +@misc{rfc8413, + author="Y. Zhuang and Q. Wu and H. Chen and A. Farrel", + title="{Framework for Scheduled Use of Resources}", + howpublished="RFC 8413 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8413", + pages="1--22", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8413.txt", + key="RFC 8413", + abstract={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.}, + keywords="Traffic Engineering, TE, Label Switched Path, LSP, MPLS, Path Computation Element, PCE, Software Defined Networking, SDN", + doi="10.17487/RFC8413", + } + +@misc{rfc8414, + author="M. Jones and N. Sakimura and J. Bradley", + title="{OAuth 2.0 Authorization Server Metadata}", + howpublished="RFC 8414 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8414", + pages="1--23", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8414.txt", + key="RFC 8414", + abstract={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.}, + keywords="OAuth, Discovery, Metadata, Discovery Metadata, Configuration Information, Authorization Server, WebFinger, JavaScript Object Notation, JSON, JSON Web Token, JWT", + doi="10.17487/RFC8414", + } + +@misc{rfc8416, + author="D. Ma and D. Mandelberg and T. Bruijnzeels", + title="{Simplified Local Internet Number Resource Management with the RPKI (SLURM)}", + howpublished="RFC 8416 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8416", + pages="1--17", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8416.txt", + key="RFC 8416", + abstract={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.}, + keywords="RPKI, Local Trust Anchor, BGPsec", + doi="10.17487/RFC8416", + } + +@misc{rfc8417, + author="P. {Hunt (Ed.)} and M. Jones and W. Denniss and M. Ansari", + title="{Security Event Token (SET)}", + howpublished="RFC 8417 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8417", + pages="1--28", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8417.txt", + key="RFC 8417", + abstract={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.}, + keywords="Identity, Security, Event, Token, Claims, JSON, JSON Web Token, JWT", + doi="10.17487/RFC8417", + } + +@misc{rfc8418, + author="R. Housley", + title="{Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 8418 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8418", + pages="1--18", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8418.txt", + key="RFC 8418", + abstract={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).}, + doi="10.17487/RFC8418", + } + +@misc{rfc8419, + author="R. Housley", + title="{Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)}", + howpublished="RFC 8419 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8419", + pages="1--9", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8419.txt", + key="RFC 8419", + abstract={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.}, + doi="10.17487/RFC8419", + } + +@misc{rfc8420, + author="Y. Nir", + title="{Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)}", + howpublished="RFC 8420 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8420", + pages="1--5", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8420.txt", + key="RFC 8420", + abstract={This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).}, + doi="10.17487/RFC8420", + } + +@misc{rfc8421, + author="P. Martinsen and T. Reddy and P. Patil", + title="{Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)}", + howpublished="RFC 8421 (Best Current Practice)", + series="Internet Request for Comments", + type="RFC", + number="8421", + pages="1--9", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8421.txt", + key="RFC 8421", + abstract={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).}, + doi="10.17487/RFC8421", + } + +@misc{rfc8422, + author="Y. Nir and S. Josefsson and M. Pegourie-Gonnard", + title="{Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier}", + howpublished="RFC 8422 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8422", + pages="1--34", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8422.txt", + key="RFC 8422", + abstract={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. This document obsoletes RFC 4492.}, + keywords="ECDSA, EdDSA", + doi="10.17487/RFC8422", + } + +@misc{rfc8423, + author="R. Housley and L. Zieglar", + title="{Reclassification of Suite B Documents to Historic Status}", + howpublished="RFC 8423 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8423", + pages="1--8", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8423.txt", + key="RFC 8423", + abstract={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.}, + keywords="x.509 v3 certificates, x.509 v2 certificate revocation lists, crl, UI suites, user interface suites, elliptic curve, ike, cryptographic algorithm policy, security application, suite b cryptography, cmc, suite b x.509 public key certificates, cryptographic algorithm policy, nsa", + doi="10.17487/RFC8423", + } + +@misc{rfc8424, + author="H. {Chen (Ed.)} and R. {Torvi (Ed.)}", + title="{Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection}", + howpublished="RFC 8424 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8424", + pages="1--28", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8424.txt", + key="RFC 8424", + abstract={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.}, + keywords="Head Protection", + doi="10.17487/RFC8424", + } + +@misc{rfc8425, + author="O. Troan", + title="{IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags}", + howpublished="RFC 8425 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8425", + pages="1--4", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8425.txt", + key="RFC 8425", + abstract={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.}, + doi="10.17487/RFC8425", + } + +@misc{rfc8426, + author="H. {Sitaraman (Ed.)} and V. Beeram and I. Minei and S. Sivabalan", + title="{Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence}", + howpublished="RFC 8426 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8426", + pages="1--12", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8426.txt", + key="RFC 8426", + abstract={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.}, + doi="10.17487/RFC8426", + } + +@misc{rfc8427, + author="P. Hoffman", + title="{Representing DNS Messages in JSON}", + howpublished="RFC 8427 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8427", + pages="1--15", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8427.txt", + key="RFC 8427", + abstract={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.}, + doi="10.17487/RFC8427", + } + +@misc{rfc8428, + author="C. Jennings and Z. Shelby and J. Arkko and A. Keranen and C. Bormann", + title="{Sensor Measurement Lists (SenML)}", + howpublished="RFC 8428 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8428", + pages="1--54", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8428.txt", + key="RFC 8428", + abstract={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.}, + keywords="IoT, data model", + doi="10.17487/RFC8428", + } + +@misc{rfc8430, + author="N. {Bahadur (Ed.)} and S. {Kini (Ed.)} and J. Medved", + title="{RIB Information Model}", + howpublished="RFC 8430 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8430", + pages="1--28", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8430.txt", + key="RFC 8430", + abstract={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.}, + keywords="RIB, info model", + doi="10.17487/RFC8430", + } + +@misc{rfc8431, + author="L. Wang and M. Chen and A. Dass and H. Ananthakrishnan and S. Kini and N. Bahadur", + title="{A YANG Data Model for the Routing Information Base (RIB)}", + howpublished="RFC 8431 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8431", + pages="1--71", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8431.txt", + key="RFC 8431", + abstract={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.}, + doi="10.17487/RFC8431", + } + +@misc{rfc8433, + author="D. Worley", + title="{A Simpler Method for Resolving Alert-Info URNs}", + howpublished="RFC 8433 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8433", + pages="1--45", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8433.txt", + key="RFC 8433", + abstract={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. 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.}, + keywords="Alert-Info, audio signals, call signaling, call transfer, resolution, signaling, signals, SIP, URN, visual signals", + doi="10.17487/RFC8433", + } + +@misc{rfc8434, + author="T. Haynes", + title="{Requirements for Parallel NFS (pNFS) Layout Types}", + howpublished="RFC 8434 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8434", + pages="1--17", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8434.txt", + key="RFC 8434", + abstract={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.}, + keywords="NFSv4", + doi="10.17487/RFC8434", + } + +@misc{rfc8435, + author="B. Halevy and T. Haynes", + title="{Parallel NFS (pNFS) Flexible File Layout}", + howpublished="RFC 8435 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8435", + pages="1--42", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8435.txt", + key="RFC 8435", + abstract={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.}, + keywords="NFSv4", + doi="10.17487/RFC8435", + } + +@misc{rfc8436, + author="G. Fairhurst", + title="{Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry}", + howpublished="RFC 8436 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8436", + pages="1--7", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8436.txt", + key="RFC 8436", + abstract={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. 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.}, + keywords="Diffserv, DSCP", + doi="10.17487/RFC8436", + } + +@misc{rfc8437, + author="C. Newman", + title="{IMAP UNAUTHENTICATE Extension for Connection Reuse}", + howpublished="RFC 8437 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8437", + pages="1--11", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8437.txt", + key="RFC 8437", + abstract={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.}, + keywords="IMAP, unauthenticate, SASL, login, authenticate, authentication", + doi="10.17487/RFC8437", + } + +@misc{rfc8438, + author="S. Bosch", + title="{IMAP Extension for STATUS=SIZE}", + howpublished="RFC 8438 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8438", + pages="1--6", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8438.txt", + key="RFC 8438", + abstract={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.}, + keywords="imap, status, size", + doi="10.17487/RFC8438", + } + +@misc{rfc8439, + author="Y. Nir and A. Langley", + title="{ChaCha20 and Poly1305 for IETF Protocols}", + howpublished="RFC 8439 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8439", + pages="1--46", + year=2018, + month=jun, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8439.txt", + key="RFC 8439", + abstract={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. 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.}, + keywords="CHACHA, CHACHA20, POLY1305, AEAD", + doi="10.17487/RFC8439", + } + +@misc{rfc8440, + author="K. Murchison and B. Gondwana", + title="{IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST}", + howpublished="RFC 8440 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8440", + pages="1--6", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8440.txt", + key="RFC 8440", + abstract={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.}, + keywords="IMAP4, LIST, MYRIGHTS", + doi="10.17487/RFC8440", + } + +@misc{rfc8441, + author="P. McManus", + title="{Bootstrapping WebSockets with HTTP/2}", + howpublished="RFC 8441 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8441", + pages="1--8", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8441.txt", + key="RFC 8441", + abstract={This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.}, + keywords="CONNECT SETTINGS", + doi="10.17487/RFC8441", + } + +@misc{rfc8442, + author="J. Mattsson and D. Migault", + title="{ECDHE\_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2}", + howpublished="RFC 8442 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8442", + pages="1--7", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8442.txt", + key="RFC 8442", + abstract={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.}, + doi="10.17487/RFC8442", + } + +@misc{rfc8443, + author="R. Singh and M. Dolly and S. Das and A. Nguyen", + title="{Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization}", + howpublished="RFC 8443 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8443", + pages="1--10", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8443.txt", + key="RFC 8443", + abstract={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.}, + keywords="SIP Resource-Priority, Resource Priority Header (rph), JSON Web Token Claim, Identity header, Authentication Service, Assertion, Verification Service", + doi="10.17487/RFC8443", + } + +@misc{rfc8445, + author="A. Keranen and C. Holmberg and J. Rosenberg", + title="{Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal}", + howpublished="RFC 8445 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8445", + pages="1--100", + year=2018, + month=jul, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8445.txt", + key="RFC 8445", + abstract={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). This document obsoletes RFC 5245.}, + keywords="NAT", + doi="10.17487/RFC8445", + } + +@misc{rfc8446, + author="E. Rescorla", + title="{The Transport Layer Security (TLS) Protocol Version 1.3}", + howpublished="RFC 8446 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8446", + pages="1--160", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8446.txt", + key="RFC 8446", + abstract={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. 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.}, + keywords="international data algorithm, symmetric, transport protocol layer, authentication, privacy", + doi="10.17487/RFC8446", + } + +@misc{rfc8447, + author="J. Salowey and S. Turner", + title="{IANA Registry Updates for TLS and DTLS}", + howpublished="RFC 8447 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8447", + pages="1--20", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8447.txt", + key="RFC 8447", + abstract={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. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.}, + doi="10.17487/RFC8447", + } + +@misc{rfc8449, + author="M. Thomson", + title="{Record Size Limit Extension for TLS}", + howpublished="RFC 8449 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8449", + pages="1--8", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8449.txt", + key="RFC 8449", + abstract={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. This replaces the maximum fragment length extension defined in RFC 6066.}, + keywords="TLS, record, IoT, encryption", + doi="10.17487/RFC8449", + } + +@misc{rfc8450, + author="J. Weaver", + title="{RTP Payload Format for VC-2 High Quality (HQ) Profile}", + howpublished="RFC 8450 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8450", + pages="1--24", + year=2018, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8450.txt", + key="RFC 8450", + abstract={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. 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).}, + keywords="rtp, vc-2, VC2, dirac", + doi="10.17487/RFC8450", + } + +@misc{rfc8451, + author="V. Singh and R. Huang and R. Even and D. Romascanu and L. Deng", + title="{Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API}", + howpublished="RFC 8451 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8451", + pages="1--18", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8451.txt", + key="RFC 8451", + abstract={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.}, + keywords="Web real-time communication", + doi="10.17487/RFC8451", + } + +@misc{rfc8453, + author="D. {Ceccarelli (Ed.)} and Y. {Lee (Ed.)}", + title="{Framework for Abstraction and Control of TE Networks (ACTN)}", + howpublished="RFC 8453 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8453", + pages="1--42", + year=2018, + month=aug, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8453.txt", + key="RFC 8453", + abstract={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. 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. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity service s.}, + keywords="SDN, Orchestration", + doi="10.17487/RFC8453", + } + +@misc{rfc8454, + author="Y. Lee and S. Belotti and D. Dhody and D. Ceccarelli and B. Yoon", + title="{Information Model for Abstraction and Control of TE Networks (ACTN)}", + howpublished="RFC 8454 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8454", + pages="1--23", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8454.txt", + key="RFC 8454", + abstract={This document provides an information model for Abstraction and Control of TE Networks (ACTN).}, + doi="10.17487/RFC8454", + } + +@misc{rfc8457, + author="B. {Leiba (Ed.)}", + title="{IMAP ``\$Important'' Keyword and ``\\Important'' Special-Use Attribute}", + howpublished="RFC 8457 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8457", + pages="1--11", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8457.txt", + key="RFC 8457", + abstract={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.}, + keywords="IMAP attributes", + doi="10.17487/RFC8457", + } + +@misc{rfc8459, + author="D. Dolson and S. Homma and D. Lopez and M. Boucadair", + title="{Hierarchical Service Function Chaining (hSFC)}", + howpublished="RFC 8459 (Experimental)", + series="Internet Request for Comments", + type="RFC", + number="8459", + pages="1--29", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8459.txt", + key="RFC 8459", + abstract={Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. 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.}, + keywords="Scalability, SFC-enabled domain, multiple control domains, SFC complexity, Hierarchy, service delivery, service complications, service offering, differentiated services, large scale network", + doi="10.17487/RFC8459", + } + +@misc{rfc8460, + author="D. Margolis and A. Brotman and B. Ramakrishnan and J. Jones and M. Risher", + title="{SMTP TLS Reporting}", + howpublished="RFC 8460 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8460", + pages="1--34", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8460.txt", + key="RFC 8460", + abstract={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.}, + keywords="DANE, MTA-STS", + doi="10.17487/RFC8460", + } + +@misc{rfc8461, + author="D. Margolis and M. Risher and B. Ramakrishnan and A. Brotman and J. Jones", + title="{SMTP MTA Strict Transport Security (MTA-STS)}", + howpublished="RFC 8461 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8461", + pages="1--29", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8461.txt", + key="RFC 8461", + abstract={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.}, + keywords="SMTP STARTTLS, Mail Security", + doi="10.17487/RFC8461", + } + +@misc{rfc8463, + author="J. Levine", + title="{A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)}", + howpublished="RFC 8463 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8463", + pages="1--7", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8463.txt", + key="RFC 8463", + abstract={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.}, + keywords="DKIM, ed25519, cryptography", + doi="10.17487/RFC8463", + } + +@misc{rfc8464, + author="R. Atarius", + title="{A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)}", + howpublished="RFC 8464 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8464", + pages="1--10", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8464.txt", + key="RFC 8464", + abstract={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.}, + keywords="MEID, instance ID, IMS", + doi="10.17487/RFC8464", + } + +@misc{rfc8465, + author="R. {Atarius (Ed.)}", + title="{Using the Mobile Equipment Identity (MEID) URN as an Instance ID}", + howpublished="RFC 8465 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8465", + pages="1--8", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8465.txt", + key="RFC 8465", + abstract={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.}, + keywords="MEID, instance ID, IMS", + doi="10.17487/RFC8465", + } + +@misc{rfc8470, + author="M. Thomson and M. Nottingham and W. Tarreau", + title="{Using Early Data in HTTP}", + howpublished="RFC 8470 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8470", + pages="1--12", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8470.txt", + key="RFC 8470", + abstract={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.}, + keywords="HTTP, TLS, replay, retry, 0-RTT, early data, status code", + doi="10.17487/RFC8470", + } + +@misc{rfc8471, + author="A. {Popov (Ed.)} and M. Nystroem and D. Balfanz and J. Hodges", + title="{The Token Binding Protocol Version 1.0}", + howpublished="RFC 8471 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8471", + pages="1--18", + year=2018, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8471.txt", + key="RFC 8471", + abstract={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.}, + keywords="Token, cookie, TLS, export, replay", + doi="10.17487/RFC8471", + } + +@misc{rfc8472, + author="A. {Popov (Ed.)} and M. Nystroem and D. Balfanz", + title="{Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation}", + howpublished="RFC 8472 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8472", + pages="1--8", + year=2018, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8472.txt", + key="RFC 8472", + abstract={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.}, + keywords="Cookie, TLS, export, replay", + doi="10.17487/RFC8472", + } + +@misc{rfc8473, + author="A. Popov and M. Nystroem and D. {Balfanz (Ed.)} and N. Harper and J. Hodges", + title="{Token Binding over HTTP}", + howpublished="RFC 8473 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8473", + pages="1--25", + year=2018, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8473.txt", + key="RFC 8473", + abstract={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. 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. 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. This document is a companion document to ``The Token Binding Protocol Version 1.0'' (RFC 8471).}, + keywords="Cookie, TLS, OAuth, export, replay", + doi="10.17487/RFC8473", + } + +@misc{rfc8474, + author="B. {Gondwana (Ed.)}", + title="{IMAP Extension for Object Identifiers}", + howpublished="RFC 8474 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8474", + pages="1--16", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8474.txt", + key="RFC 8474", + abstract={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.}, + keywords="IMAP, email", + doi="10.17487/RFC8474", + } + +@misc{rfc8478, + author="Y. Collet and M. {Kucherawy (Ed.)}", + title="{Zstandard Compression and the application/zstd Media Type}", + howpublished="RFC 8478 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8478", + pages="1--54", + year=2018, + month=oct, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8478.txt", + key="RFC 8478", + abstract={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). 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.}, + keywords="Compression", + doi="10.17487/RFC8478", + } + +@misc{rfc8479, + author="N. Mavrogiannopoulos", + title="{Storing Validation Parameters in PKCS\#8}", + howpublished="RFC 8479 (Informational)", + series="Internet Request for Comments", + type="RFC", + number="8479", + pages="1--8", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8479.txt", + key="RFC 8479", + abstract={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. The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard.}, + keywords="private keys, validation parameters, PKCS\#8", + doi="10.17487/RFC8479", + } + +@misc{rfc8481, + author="R. Bush", + title="{Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)}", + howpublished="RFC 8481 (Proposed Standard)", + series="Internet Request for Comments", + type="RFC", + number="8481", + pages="1--5", + year=2018, + month=sep, + issn="2070-1721", + publisher="RFC Editor", + institution="RFC Editor", + organization="RFC Editor", + address="Fremont, CA, USA", + url="https://www.rfc-editor.org/rfc/rfc8481.txt", + key="RFC 8481", + abstract={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.}, + keywords="security, routing", + doi="10.17487/RFC8481", + } + diff --git a/2018/sponsor19/sponsor19.bib b/2018/sponsor19/sponsor19.bib new file mode 100644 index 0000000..64a0f82 --- /dev/null +++ b/2018/sponsor19/sponsor19.bib @@ -0,0 +1,738 @@ + +@inproceedings{wecsr10measuring-tor, + title = {A Case Study on Measuring Statistical Data in the {T}or Anonymity Network}, + author = {Karsten Loesing and Steven J. Murdoch and Roger Dingledine}, + booktitle = {Proceedings of the Workshop on Ethics in Computer Security Research (WECSR + 2010)}, + year = {2010}, + month = {January}, + location = {Tenerife, Canary Islands, Spain}, + publisher = {Springer}, + series = {LNCS}, + www_tags = {selected}, + www_pdf_url = {https://www.cl.cam.ac.uk/~sjm217/papers/wecsr10measuring.pdf}, + www_section = {Anonymous communication}, +} + +@inproceedings{tor-usage-priv-measurement-imc18, + author = {Akshaya Mani and + T. Wilson{-}Brown and + Rob Jansen and + Aaron Johnson and + Micah Sherr}, + title = {Understanding Tor Usage with Privacy-Preserving Measurement}, + booktitle = {Proceedings of the Internet Measurement Conference 2018, {IMC} 2018, + Boston, MA, USA, October 31 - November 02, 2018}, + pages = {175--187}, + year = {2018}, + url = {https://doi.acm.org/10.1145/3278532.3278549}, + doi = {10.1145/3278532.3278549}, + timestamp = {Sat, 03 Nov 2018 18:26:13 +0100}, + biburl = {https://dblp.org/rec/bib/conf/imc/ManiWJJS18}, + bibsource = {dblp computer science bibliography, https://dblp.org} +} + +@article{WrightDF15, + author = {Joss Wright and + Alexander Darer and + Oliver Farnan}, + title = {Detecting Internet Filtering from Geographic Time Series}, + journal = {CoRR}, + volume = {abs/1507.05819}, + year = {2015}, + url = {https://arxiv.org/abs/1507.05819}, + archivePrefix = {arXiv}, + eprint = {1507.05819}, + timestamp = {Mon, 13 Aug 2018 16:46:35 +0200}, + biburl = {https://dblp.org/rec/bib/journals/corr/WrightDF15}, + bibsource = {dblp computer science bibliography, https://dblp.org} +} + +@inproceedings{torspinISC08, + title = {Compromising Anonymity Using Packet Spinning}, + author = {Vasilis Pappas and Elias Athanasopoulos and Sotiris Ioannidis and Evangelos P. + Markatos}, + booktitle = {Proceedings of the 11th Information Security Conference (ISC 2008)}, + year = {2008}, + month = {September}, + location = {Taipei, Taiwan}, + www_tags = {selected}, + www_pdf_url = {https://www.ics.forth.gr/dcs/Activities/papers/torspin.isc08.pdf}, + www_section = {Anonymous communication}, +} + +@inproceedings{pets2011-defenestrator, + title = {Defenestra{T}or: Throwing out Windows in {T}or}, + author = {Mashael AlSabah and Kevin Bauer and Ian Goldberg and Dirk Grunwald and Damon McCoy and Stefan Savage and Geoffrey Voelker}, + booktitle = {Proceedings of the 11th Privacy Enhancing Technologies Symposium (PETS 2011)}, + year = {2011}, + month = {July}, + location = {Waterloo, Canada}, + www_pdf_url = {https://cs.uwaterloo.ca/~iang/pubs/defenestrator.pdf}, +} + +@article{peerflow-popets17, + author = {Aaron Johnson and + Rob Jansen and + Nicholas Hopper and + Aaron Segal and + Paul Syverson}, + title = {Peer{F}low: Secure Load Balancing in {T}or}, + journal = {PoPETs}, + volume = {2017}, + number = {2}, + pages = {74--94}, + year = {2017}, + url = {https://doi.org/10.1515/popets-2017-0017}, + doi = {10.1515/popets-2017-0017}, + timestamp = {Sat, 27 May 2017 14:24:30 +0200}, + biburl = {https://dblp.org/rec/bib/journals/popets/JohnsonJHSS17}, + bibsource = {dblp computer science bibliography, https://dblp.org} +} + +@techreport{tor-blocking, + title = {Design of a blocking-resistant anonymity system}, + author = {Roger Dingledine and Nick Mathewson}, + institution = {The Tor Project}, + number = {2006-1}, + year = {2006}, + month = {November}, + www_tags = {selected}, + www_section = comm, + www_important = {1}, + www_pdf_url = {https://svn.torproject.org/svn/projects/design-paper/blocking.pdf}, +} + +@inproceedings{flashproxy-pets12, + title={Evading Censorship with Browser-Based Proxies}, + author={David Fifield and Nate Hardison and Jonathan Ellithorpe and Emily Stark and Roger Dingledine and Phil Porras and Dan Boneh}, + booktitle = {Proceedings of the 12th Privacy Enhancing Technologies Symposium (PETS 2012)}, + month={July}, + year={2012}, + publisher={Springer}, + www_tags = {selected}, + www_section= censorship, + www_pdf_url= {https://crypto.stanford.edu/flashproxy/flashproxy.pdf} +} + +@inproceedings{botnetfc14, + title={Challenges in protecting {T}or hidden services from botnet abuse}, + author={Nicholas Hopper}, + booktitle={Proceedings of Financial Cryptography and Data Security (FC'14)}, + year = {2014}, + month = {March}, + www_section = comm, + www_pdf_url = "https://fc14.ifca.ai/papers/fc14_submission_152.pdf", + www_tags={selected}, +} + +@misc{tor-pt-spec, +title = {Tor Pluggable Transport Specification}, +key = {Tor Pluggable Transport Specification}, +howpublished = {\url{https://spec.torproject.org/pt-spec}}, +} + +@misc{tor-spec-tap, +title = {{Tor Protocol Specification: The TAP handshake}}, +author = {Roger Dingledine and Nick Mathewson}, +howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt\#n1043}}, +} + +@misc{tor-spec-ntor, +title = {{Tor Protocol Specification: The "ntor" handshake}}, +author = {Roger Dingledine and Nick Mathewson}, +howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt\#n1090}}, +} + + +@misc{prop-255, +title = {{Tor Protocol Specification Proposal 255}}, +author = {Tom van der Woerdt}, +howpublished = {\url{https://github.com/torproject/torspec/blob/master/proposals/255-hs-load-balancing.txt}}, +} + + +@misc{tor-browser-design, +title = {The Design and Implementation of the {T}or {B}rowser}, +key = {The Design and Implementation of the {T}or {B}rowser}, +howpublished = {\\\url{https://www.torproject.org/projects/torbrowser/design/}}, +} + +@misc{torperf, +title = {{Torperf}}, +key = {{Torperf}}, +howpublished = {\\\url{https://gitweb.torproject.org/torperf.git/}}, +} + +@misc{onionperf, +title = {{OnionPerf}}, +key = {{OnionPerf}}, +howpublished = {\\\url{https://github.com/robgjansen/onionperf}}, +} + +@misc{meek, +title = {meek}, +author = {David Fifield}, +howpublished = {\url{https://trac.torproject.org/projects/tor/wiki/doc/meek}} +} + +@misc{research-blog-post, +title = {{Tor at the Heart: PETS and the Privacy Research Community}}, +author = {Roger Dingledine}, +howpublished = {\\\url{https://blog.torproject.org/tor-heart-pets-and-privacy-research-community}} +} + +@misc{botnet-2013, +title = {{How to handle millions of new Tor clients}}, +author = {Roger Dingledine}, +howpublished = {\\\url{https://blog.torproject.org/how-handle-millions-new-tor-clients}} +} + +@misc{gettor, +title = {{GetTor}}, +key = {GetTor}, +howpublished = {\\\url{https://www.torproject.org/projects/gettor}} +} + +@misc{collector, +title = {{CollecTor}}, +key = {CollecTor}, +howpublished = {\\\url{https://metrics.torproject.org/collector.html}} +} + +@misc{tor-metrics, +title = {{Tor Metrics}}, +key = {Tor Metrics}, +howpublished = {\\\url{https://metrics.torproject.org/}} +} + +@misc{tor-metrics-news, +title = {{Tor Metrics News}}, +key = {Tor Metrics News}, +howpublished = {\\\url{https://metrics.torproject.org/news.html}} +} + +@misc{max-mind-geolite2, +title = {{GeoLite2 Free Downloadable Databases}}, +key = {GeoLite2 Free Downloadable Databases}, +howpublished = {\\\url{https://dev.maxmind.com/geoip/geoip2/geolite2/}} +} + +@misc{ip2location, +title = {{IP2Location}}, +key = {IP2Location}, +howpublished = {\\\url{https://www.ip2location.com/}} +} + +@misc{ripe-stat, +title = {{RIPEstat}}, +key = {RIPEstat}, +howpublished = {\\\url{https://stat.ripe.net/}} +} + +@misc{tor-metrics-geo-study, +title = {{Improve AS number and name coverage (switch maxmind to RIPE Stat)}}, +key = {Improve AS number and name coverage (switch maxmind to RIPE Stat)}, +howpublished = {\\\url{https://trac.torproject.org/projects/tor/ticket/26585\#comment:3}} +} + +@misc{tencent-wiki, +title = {{Tencent}}, +key = {Tencent}, +howpublished = {\\\url{https://en.wikipedia.org/wiki/Tencent}} +} + +@misc{tencent-social, +title = {{Tencent social networks}}, +key = {Tencent social networks}, +howpublished = {\\\url{https://www.tencent.com/en-us/system.html}} +} + +@misc{popular-android-apps-wiki, +title = {{List of most-downloaded Google Play applications}}, +key = {List of most-downloaded Google Play applications}, +howpublished = {\\\url{https://en.wikipedia.org/wiki/List_of_most-downloaded_Google_Play_applications#Paid_applications_with_one_million_or_more_downloads}} +} + +@misc{china-blocked-apps, +title = {{List of Websites and Apps Blocked in China [Updated Aug 2018]}}, +author = {SLC Team}, +howpublished = {\\\url{https://startuplivingchina.com/list-websites-apps-blocked-china/}} +} + +@misc{udhr, +title = {{Universal Declaration of Human Rights}}, +author = {United Nations}, +howpublished = {\\\url{https://www.un.org/en/universal-declaration-human-rights/}} +} + +@misc{ftr, +title = {{The Freedom to Read Statement}}, +author = {American Library Association}, +howpublished = {\\\url{http://www.ala.org/advocacy/intfreedom/freedomreadstatement}} +} + +@misc{tencent-surveillance, +title = {{WeChat's privacy issues mean you should delete China's No. 1 messaging app }}, +author = {Angus Grigg }, +howpublished = {\\\url{https://www.afr.com/news/world/asia/wechats-privacy-issues-mean-you-should-delete-chinas-no1-messaging-app-20180221-h0wgct}} +} + +@misc{russia-amazon-google, +title = {{Censorship in the Age of Large Cloud Providers}}, +author = {Bruce Schneier}, +howpublished = {\\\url{https://www.schneier.com/essays/archives/2018/06/censorship_in_the_ag.html}} +} + +@misc{sbws, +title = {{Simple Bandwidth Scanner technical details}}, +author = {Matt Traudt and juga}, +howpublished = {\\\url{https://sbws.readthedocs.io/en/latest/specification.html}} +} + +@misc{load-2017, +title = {{Re: could Tor devs provide an update on DOS attacks?}}, +author = {Roger Dingledine}, +howpublished = {\\\url{https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html}} +} + +@misc{research-portal, +title = {{Tor Research Portal}}, +key ={Tor Research Portal}, +howpublished = {\\\url{https://research.torproject.org/}} +} + +@misc{metrics-lib, +title = {{Tor Metrics Library}}, +key ={Tor Metrics Library}, +howpublished = {\\\url{https://metrics.torproject.org/metrics-lib.html}} +} + +@misc{pluggable-transports-list, +title = {List of Pluggable Transports}, +key = {List of Pluggable Transports}, +howpublished = {\\\url{https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/list}}, +} + +@misc{trsb, +title = {{Tor Research Safety Board}}, +key = {{Tor Research Safety Board}}, +howpublished = {\url{https://research.torproject.org/safetyboard.html}}, +} + +@misc{snowflake, +title = {Snowflake}, +key = {Snowflake}, +howpublished = {\url{https://trac.torproject.org/projects/tor/wiki/doc/Snowflake}}, +} + +@misc{securedrop, +title = {SecureDrop: The open-source whistleblower submission system}, +key = {SecureDrop: The open-source whistleblower submission system}, +howpublished = {\url{https://securedrop.org/}}, +} + +@misc{orbot, +title = {{Orbot: Tor for Android}}, +key = {Orbot: Tor for Android}, +howpublished = {\url{https://guardianproject.info/apps/orbot/}}, +} + +@misc{guardianproj, +title = {{The Guardian Project}}, +key = {The Guardian Project}, +howpublished = {\url{https://guardianproject.info/}}, +} + +@misc{adversary-lab, +title = {{Adversary Lab}}, +key = {Adversary Lab}, +howpublished = {\url{https://github.com/OperatorFoundation/AdversaryLab}}, +} + +@misc{tails, +title = {{TAILS: The Amnesic Incognito Live System}}, +key = {TAILS: The Amnesic Incognito Live System}, +howpublished = {\url{https://tails.boum.org/}}, +} + +@misc{whonix, +title = {{Whonix: A High Security Method of Surfing the Internet}}, +key = {Whonix: A High Security Method of Surfing the Internet}, +howpublished = {\url{https://www.whonix.org/}}, +} + +@misc{qubes, +title = {{Qubes OS: A reasonably secure operating system}}, +key = {Qubes OS: A reasonably secure operating system}, +howpublished = {\url{https://www.qubes-os.org/}}, +} + +@misc{icepa, +title = {{iCepa: iOS system-wide VPN based Tor client}}, +key = {iCepa: iOS system-wide VPN based Tor client}, +howpublished = {\url{https://github.com/iCepa/iCepa}}, +} + +@misc{globaleaks, +title = {GlobaLeaks: The open-source whistleblowing software}, +key = {GlobaLeaks: The open-source whistleblowing software}, +howpublished = {\url{https://www.globaleaks.org/}}, +} + +@misc{cliqz, +title = {Cliqz}, +key = {Cliqz}, +howpublished = {\url{https://cliqz.com/en/}}, +} + +@misc{brave, +title = {Brave}, +key = {Brave}, +howpublished = {\url{https://brave.com/}}, +} + +@misc{witness, +title = {Witness}, +key = {Witness}, +howpublished = {\url{https://witness.org/}}, +} + +@misc{onion-browser, +title = {{Onion Browser: An open-source, privacy-enhancing web browser for iOS.}}, +key = {{Onion Browser: An open-source, privacy-enhancing web browser for iOS.}}, +howpublished = {\url{https://onionbrowser.com/}}, +} + +@misc{briar, +title = {Briar: Secure messaging, anywhere}, +key = {Briar: Secure messaging, anywhere}, +howpublished = {\url{https://briarproject.org/}}, +} + +@misc{chatsecure, +title = {ChatSecure: Free and open source encrypted chat for iOS}, +key = {ChatSecure: Free and open source encrypted chat for iOS}, +howpublished = {\url{https://chatsecure.org/}}, +} + +@misc{tor-birdy, +title = {TorBirdy}, +key = {TorBirdy}, +howpublished = {\url{https://trac.torproject.org/projects/tor/wiki/torbirdy}}, +} + +@misc{ricochet, +title = {Ricochet}, +key = {Ricochet}, +howpublished = {\url{https://ricochet.im/}}, +} + +@misc{onionshare, +title = {OnionShare}, +key = {OnionShare}, +howpublished = {\url{https://onionshare.org/}}, +} + +@misc{haven, +title = {Haven: Keep Watch}, +key = {Haven: Keep Watch}, +howpublished = {\url{https://guardianproject.github.io/haven/}}, +} + +@misc{resumable-js, +title = {Resumable.js}, +key = {Resumable.js}, +howpublished = {\url{http://www.resumablejs.com/}}, +} + +@misc{opendesignkit, +title = {Open Design Process}, +key = {Open Design Process}, +howpublished = {\url{http://opendesignkit.org/process/}}, +} + +@misc{china-vpn-ban, +title = {VPNs can still be used in China despite March 31 ban}, +key = {VPNs can still be used in China despite March 31 ban}, +howpublished = {\url{https://www.zdnet.com/article/vpns-can-still-be-used-in-china-despite-march-31-ban/}}, +} + +@misc{egypt-internet-users, +title = {{ICT Indicators in Brief (Egypt)}}, +key = {ICT Indicators in Brief}, +howpublished = {\url{www.mcit.gov.eg/Upcont/Documents/Publications_2122017000_Flyer_new_December_2016_EN_21_02_2017.pdf}}, +} + +@misc{ethiopia-new-pm, +title = {{Ethiopia's parliament swears in new prime minister}}, +author = {Meron Moges-Gerbi and Chris Giles}, +howpublished = {\url{https://edition.cnn.com/2018/04/02/africa/ethiopia-new-pm-abiy-ahmed/index.html}}, +} + +@misc{ux-research, +title = {Tor UX Research}, +key = {Tor UX Research}, +howpublished = {\url{https://trac.torproject.org/projects/tor/ticket/27010}}, +} + +@misc{tor-uplift, +title = {Tor Uplift Project}, +key = {Tor Uplift Project}, +howpublished = {\url{https://wiki.mozilla.org/Security/Tor_Uplift}}, +} + +@misc{infolabe, +title = {infolabe-anomalies - Detected anomalies in Tor user numbers}, +key = {Infolabe}, +howpublished = {\url{http://lists.infolabe.net/lists/listinfo/infolabe-anomalies}}, +} + +@misc{ooni-probe, +title = {OONI Probe}, +key = {OONI Probe}, +howpublished = {\url{https://ooni.torproject.org/install/}}, +} + +@misc{ooni-nettest, +title = {OONI Tests}, +key = {OONI Tests}, +howpublished = {\url{https://ooni.torproject.org/nettest/}}, +} + +@inproceedings{ooni-paper, + author = {Arturo Filast\`{o} and Jacob Appelbaum}, + booktitle = {Free and Open Communications on the Internet}, + publisher = {USENIX}, + title = {{OONI}: Open Observatory of Network Interference}, + year = {2012}, + url = {https://www.usenix.org/system/files/conference/foci12/foci12-final12.pdf}, +} + +@misc{ooni-explorer, +title = {{OONI Explorer}}, +key = {{OONI Explorer}}, +howpublished = {\url{https://explorer.ooni.torproject.org/world/}}, +} + +@misc{ooni-explorer-egypt, +title = {{OONI Explorer Egypt}}, +key = {{OONI Explorer Egypt}}, +howpublished = {\url{https://explorer.ooni.torproject.org/country/EG}}, +} + +@misc{ooni-explorer-ethiopia, +title = {{OONI Explorer Ethiopia}}, +key = {{OONI Explorer Ethiopia}}, +howpublished = {\url{https://explorer.ooni.torproject.org/country/ET}}, +} + +@misc{ooni-explorer-china, +title = {{OONI Explorer China}}, +key = {{OONI Explorer China}}, +howpublished = {\url{https://explorer.ooni.torproject.org/country/CN}}, +} + +@misc{ooni-explorer-iran, +title = {{OONI Explorer Iran}}, +key = {{OONI Explorer Iran}}, +howpublished = {\url{https://explorer.ooni.torproject.org/country/IR}}, +} + +@misc{ooni-explorer-turkey, +title = {{OONI Explorer Turkey}}, +key = {{OONI Explorer Turkey}}, +howpublished = {\url{https://explorer.ooni.torproject.org/country/TR}}, +} + +@misc{ooni-explorer-venezuela, +title = {{OONI Explorer Venezuela}}, +key = {{OONI Explorer Venezuela}}, +howpublished = {\url{https://explorer.ooni.torproject.org/country/VE}}, +} + +@misc{ooni-stats, +title = {{OONI Measurement Statistics}}, +key = {{OONI Measurement Statistics}}, +howpublished = {\url{https://api.ooni.io/stats}}, +} + +@misc{ooni-partner-prog, +title = {{OONI Partnership Program}}, +key = {{OONI Partnership Program}}, +howpublished = {\url{https://ooni.torproject.org/get-involved/partnership-program/}}, +} + +@misc{ooni-egypt-summary, +title = {{The State of Internet Censorship in Egypt - Summary}}, +author = {Leonid Evdokimov and Maria Xynou and Mohammad El-Taher and Hassan Al-Azhary and Sarah Mohsen}, +howpublished = {\url{https://ooni.torproject.org/post/egypt-internet-censorship/}}, +} + +@misc{ooni-egypt-report, +title = {{The State of Internet Censorship in Egypt - Full Report}}, +author = {Mohammad El-Taher and Hassan Al-Azhary and Sarah Mohsen and +Leonid Evdokimov and Maria Xynou}, +howpublished = {\url{https://ooni.torproject.org/documents/Egypt-Internet-Censorship-AFTE-OONI-2018-07.pdf}}, +} + +@misc{ooni-ethiopia, +title = {{Ethiopia: Evidence of social media blocking and internet censorship}}, +author = {Maria Xynou and Arturo Filast\`{o} and Amnesty International and Girma Walabuma}, +howpublished = {\url{https://ooni.torproject.org/post/ethiopia-report/}}, +} + +@misc{ooni-ethiopia-unblock, +title = {{Ethiopia: Verifying the unblocking of websites}}, +author ={Berhan Taye and Maria Xynou and Leonid Evdokimov and Moses Karanja}, +howpublished = {\url{https://ooni.torproject.org/post/ethiopia-unblocking/}}, +} + +@misc{ooni-iran-report, +title = {{Internet Censorship in Iran: Network Measurement Findings from 2014-2017}}, +author = {Maria Xynou and Arturo Filast\`{o} and Mahsa Alimardani and Sina Kouhi and Kyle Bowen and Vmon and Amin Sabeti}, +howpublished = {\url{https://ooni.torproject.org/post/iran-internet-censorship/}}, +} + +@misc{ooni-venezuela-report, +title = {{The State of Internet Censorship in Venezuela}}, +author = {Mariengracia Chirinos and Andrés Azpúrua and Leonid Evdokimov and Maria Xynou}, +howpublished = {\url{https://ooni.torproject.org/post/venezuela-internet-censorship/}}, +} + +@misc{bbc-ethiopia-protests, +title = {{What is behind Ethiopia's wave of protests?}}, +key = {{What is behind Ethiopia's wave of protests?}}, +howpublished = {\url{https://www.bbc.com/news/world-africa-36940906}}, +} + +@misc{bbc-uganda-social-media-tax, +title = {{Uganda imposes WhatsApp and Facebook tax 'to stop gossip'}}, +key = {{Uganda imposes WhatsApp and Facebook tax 'to stop gossip'}}, +howpublished = {\url{https://www.bbc.com/news/world-africa-44315675}}, +} + +@misc{venezuela-blocks-tor, +title = {{Venezuela blocks access to the Tor network}}, +key = {{Venezuela blocks access to the Tor network}}, +howpublished = {\url{https://www.accessnow.org/venezuela-blocks-tor/}}, +} + +@techreport{dos-techreport, + author = {Nick Mathewson}, + title = {Denial-of-service attacks in {Tor}: Taxonomy and defenses}, + institution = {The Tor Project}, + number = {2015-10-001}, + year = {2015}, + month = {October}, + url = {https://research.torproject.org/techreports/dos-taxonomy-2015-10-29.pdf} +} + +@article{domain-fronting, + title = {Blocking-resistant communication through domain fronting}, + author = {David Fifield and Chang Lan and Rod Hynes and Percy Wegmann and Vern Paxson}, + journal = {Proceedings on Privacy Enhancing Technologies}, + volume = {2015}, + number = {2}, + year = {2015}, + pages = {46--64}, +} + +@article{torlauncher-pets2017, + title = {A Usability Evaluation of {T}or Launcher}, + author = {Linda Lee and David Fifield and Nathan Malkin and Ganesh Iyer and Serge Egelman and David Wagner}, + journal = {Proceedings on Privacy Enhancing Technologies}, + volume = {2017}, + number = {3}, + year = {2017}, + month = {July}, +} + +@inproceedings{pets13-splitting, + title = {The Path Less Travelled: Overcoming {T}or's Bottlenecks with Traffic Splitting}, + author = {Mashael Alsabah and Kevin Bauer and Tariq Elahi and Ian Goldberg}, + booktitle = {Proceedings of the 13th Privacy Enhancing Technologies Symposium (PETS 2013)}, + year = {2013}, + month = {July}, +} + +@article{HILBERT2016567, +title = "The bad news is that the digital access divide is here to stay: Domestically installed bandwidths among 172 countries for 1986–2014", +journal = "Telecommunications Policy", +volume = "40", +number = "6", +pages = "567 - 581", +year = "2016", +issn = "0308-5961", +doi = "https://doi.org/10.1016/j.telpol.2016.01.006", +url = "https://www.sciencedirect.com/science/article/pii/S0308596116000276", +author = "Martin Hilbert", +keywords = "Digital divide, Broadband, Bandwidth, International, Global, Gini index, Inequality" +} + +@inproceedings{Kung1994, + author = {Kung, H. T. and Blackwell, Trevor and Chapman, Alan}, + title = {Credit-based Flow Control for ATM Networks: Credit Update Protocol, Adaptive Credit Allocation and Statistical Multiplexing}, + booktitle = {Proceedings of the Conference on Communications Architectures, Protocols and Applications}, + series = {SIGCOMM '94}, + year = {1994}, + isbn = {0-89791-682-4}, + location = {London, United Kingdom}, + pages = {101--114}, + numpages = {14}, + url = {https://doi.acm.org/10.1145/190314.190324}, + doi = {10.1145/190314.190324}, + acmid = {190324}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@TechReport{fileapi, + author = "Marijn Kruisselbrink", + title = "File {API}", + month = oct, + note = "https://www.w3.org/TR/2017/WD-FileAPI-20171026/", + year = "2017", + bibsource = "http://w2.syronex.com/jmr/w3c-biblio", + type = "{W3C} Working Draft", + institution = "W3C", +} + +@inproceedings{psc-ccs2017, + author = {Ellis Fenske and Akshaya Mani and Aaron Johnson and Micah Sherr}, + title = {Distributed Measurement with Private Set-Union Cardinality}, + booktitle = {Proceedings of the 24th ACM Conference on Computer and Communications Security (CCS '17)}, + year = {2017}, + publisher = {ACM} +} + +@techreport{why-slow, + author = {Roger Dingledine and Steven J. Murdoch}, + title = {Performance Improvements on {Tor} or, Why {Tor} is slow and what we're going to do about it}, + institution = {The Tor Project}, + number = {2009-11-001}, + year = {2009}, + month = {November}, + url = {https://research.torproject.org/techreports/performance-2009-11-09.pdf} +} + +@inproceedings{jansen14-kist, + title = {Never Been {KIST}: Tor's Congestion Management Blossoms with Kernel-Informed Socket Transport}, + author = {Rob Jansen and John Geddes and Chris Wacek and Micah Sherr and Paul Syverson}, + booktitle = {Proceedings of 23rd USENIX Security Symposium (USENIX Security 14)}, + year = {2014}, + month = {August}, + address = {San Diego, CA}, + publisher = {USENIX Association}, +} + +@inproceedings{greatfirewall-tor, + Author = {Philipp Winter and Stefan Lindskog}, + Booktitle = {USENIX Workshop on Free and Open Communications on the Internet (FOCI)}, + Date-Added = {2013-11-15 02:37:04 +0000}, + Date-Modified = {2013-11-15 02:38:17 +0000}, + Keywords = {anonymity, censorship}, + Title = {{How the Great Firewall of China is Blocking Tor}}, + Year = {2012} +} + diff --git a/2018/sponsor19/torlogo.png b/2018/sponsor19/torlogo.png new file mode 100644 index 0000000..150568f Binary files /dev/null and b/2018/sponsor19/torlogo.png differ diff --git a/2018/sponsor19/tortechreports.bib b/2018/sponsor19/tortechreports.bib new file mode 100644 index 0000000..f9a2924 --- /dev/null +++ b/2018/sponsor19/tortechreports.bib @@ -0,0 +1,461 @@ +@techreport{tor-2017-04-001, + author = {Karin Herm}, + title = {Privacy analysis of {Tor}'s in-memory statistics}, + institution = {The Tor Project}, + number = {2017-04-001}, + year = {2017}, + month = {April}, + url = {https://research.torproject.org/techreports/privacy-in-memory-2017-04-28.pdf} +} + +@techreport{tor-2015-10-001, + author = {Nick Mathewson}, + title = {Denial-of-service attacks in {Tor}: Taxonomy and defenses}, + institution = {The Tor Project}, + number = {2015-10-001}, + year = {2015}, + month = {October}, + url = {https://research.torproject.org/techreports/dos-taxonomy-2015-10-29.pdf} +} + +@techreport{tor-2015-04-001, + author = {David Goulet and Aaron Johnson and George Kadianakis and Karsten Loesing}, + title = {Hidden-service statistics reported by relays}, + institution = {The Tor Project}, + number = {2015-04-001}, + year = {2015}, + month = {April}, + url = {https://research.torproject.org/techreports/hidden-service-stats-2015-04-28.pdf} +} + +@techreport{tor-2015-01-001, + author = {George Kadianakis and Karsten Loesing}, + title = {Extrapolating network totals from hidden-service statistics}, + institution = {The Tor Project}, + number = {2015-01-001}, + year = {2015}, + month = {January}, + url = {https://research.torproject.org/techreports/extrapolating-hidserv-stats-2015-01-31.pdf} +} + +@techreport{tor-2014-10-001, + author = {Virgil Griffith}, + title = {{Tor} growth rates and improving {Torperf} throughput}, + institution = {The Tor Project}, + number = {2014-10-001}, + year = {2014}, + month = {October}, + url = {https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf} +} + +@techreport{tor-2013-11-001, + author = {Nicholas Hopper}, + title = {Protecting {Tor} from botnet abuse in the long term}, + institution = {The Tor Project}, + number = {2013-11-001}, + year = {2013}, + month = {November}, + url = {https://research.torproject.org/techreports/botnet-tr-2013-11-20.pdf} +} + +@techreport{tor-2013-10-002, + author = {Karsten Loesing and Sathyanarayanan Gunasekaran and Kevin Butler}, + title = {Requirements and Software Design for a better {Tor} Performance Measurement Tool}, + institution = {The Tor Project}, + number = {2013-10-002}, + year = {2013}, + month = {October}, + url = {https://research.torproject.org/techreports/torperf2-2013-10-30.pdf} +} + +@techreport{tor-2013-10-001, + author = {Karsten Loesing and Steven J. Murdoch and Rob Jansen}, + title = {Evaluation of a libutp-based {Tor} datagram implementation}, + institution = {The Tor Project}, + number = {2013-10-001}, + year = {2013}, + month = {October}, + url = {https://research.torproject.org/techreports/libutp-2013-10-30.pdf} +} + +@techreport{tor-2013-06-001, + author = {Runa A. Sandvik}, + title = {Forensic Analysis of the {Tor Browser Bundle} on {OS X}, + {Linux}, and {Windows}}, + institution = {The Tor Project}, + number = {2013-06-001}, + year = {2013}, + month = {June}, + url = {https://research.torproject.org/techreports/tbb-forensic-analysis-2013-06-28.pdf} +} + +@techreport{tor-2013-02-001, + author = {Philipp Winter}, + title = {Design Requirements for a {Tor} Censorship Analysis Tool}, + institution = {The Tor Project}, + number = {2013-02-001}, + year = {2013}, + month = {February}, + url = {https://research.torproject.org/techreports/censorship-analysis-tool-2013-02-06.pdf} +} + +@techreport{tor-2012-10-001, + author = {Karsten Loesing}, + title = {Counting daily bridge users}, + institution = {The Tor Project}, + number = {2012-10-001}, + year = {2012}, + month = {October}, + url = {https://research.torproject.org/techreports/counting-daily-bridge-users-2012-10-24.pdf} +} + +@techreport{tor-2012-08-001, + author = {Jacob Appelbaum}, + title = {{Tor} and {NAT} devices: increasing bridge \& relay reachability or, enabling the use of {NAT-PMP} and {UPnP} by default}, + institution = {The Tor Project}, + number = {2012-08-001}, + year = {2012}, + month = {August}, + url = {https://research.torproject.org/techreports/tor-nat-plan-2012-08-22.pdf} +} + +@techreport{tor-2012-04-001, + author = {Karsten Loesing}, + title = {What fraction of our bridges are not reporting usage statistics?}, + institution = {The Tor Project}, + number = {2012-04-001}, + year = {2012}, + month = {April}, + url = {https://research.torproject.org/techreports/bridge-report-usage-stats-2012-04-30.pdf} +} + +@techreport{tor-2012-03-003, + author = {Steven J. Murdoch and George Kadianakis}, + title = {Pluggable Transports Roadmap}, + institution = {The Tor Project}, + number = {2012-03-003}, + year = {2012}, + month = {March}, + url = {https://research.torproject.org/techreports/pluggable-roadmap-2012-03-17.pdf} +} + +@techreport{tor-2012-03-002, + author = {Steven J. Murdoch}, + title = {Datagram Testing Plan}, + institution = {The Tor Project}, + number = {2012-03-002}, + year = {2012}, + month = {March}, + url = {https://research.torproject.org/techreports/datagram-testing-plan-2012-03-16.pdf} +} + +@techreport{tor-2012-03-004, + author = {George Kadianakis}, + title = {Packet Size Pluggable Transport and Traffic Morphing}, + institution = {The Tor Project}, + number = {2012-03-004}, + year = {2012}, + month = {March}, + url = {https://research.torproject.org/techreports/morpher-2012-03-13.pdf} +} + +@techreport{tor-2012-03-001, + author = {Karsten Loesing}, + title = {What if the {Tor} network had 50,000 bridges}, + institution = {The Tor Project}, + number = {2012-03-001}, + year = {2012}, + month = {March}, + url = {https://research.torproject.org/techreports/bridge-scaling-2012-03-09.pdf} +} + +@techreport{tor-2011-12-001, + author = {Roger Dingledine}, + title = {Five ways to test bridge reachability}, + institution = {The Tor Project}, + number = {2011-12-001}, + year = {2011}, + month = {December}, + url = {https://research.torproject.org/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf} +} + +@techreport{tor-2011-11-002, + author = {Sebastian Hahn}, + title = {Different Ways to Use a Bridge}, + institution = {The Tor Project}, + number = {2011-11-002}, + year = {2011}, + month = {November}, + url = {https://research.torproject.org/techreports/different-ways-use-bridge-2011-11-29.pdf} +} + +@techreport{tor-2011-11-001, + author = {Steven J. Murdoch}, + title = {Comparison of {Tor} Datagram Designs}, + institution = {The Tor Project}, + number = {2011-11-001}, + year = {2011}, + month = {November}, + url = {https://research.torproject.org/techreports/datagram-comparison-2011-11-07.pdf} +} + +@techreport{tor-2011-10-002, + author = {Roger Dingledine}, + title = {Ten ways to discover {Tor} bridges}, + institution = {The Tor Project}, + number = {2011-10-002}, + year = {2011}, + month = {October}, + url = {https://research.torproject.org/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf} +} + +@techreport{tor-2011-10-001, + author = {Karsten Loesing}, + title = {An Analysis of {Tor} Bridge Stability---Making {BridgeDB} give out at least one stable bridge per user}, + institution = {The Tor Project}, + number = {2011-10-001}, + year = {2011}, + month = {October}, + url = {https://research.torproject.org/techreports/bridge-stability-2011-10-31.pdf} +} + +@techreport{tor-2011-09-002, + author = {Karsten Loesing}, + title = {Case study: Learning whether a {Tor} bridge is blocked by looking at its aggregate usage statistics, Part one}, + institution = {The Tor Project}, + number = {2011-09-002}, + year = {2011}, + month = {September}, + url = {https://research.torproject.org/techreports/blocking-2011-09-15.pdf} +} + +@techreport{tor-2011-09-001, + author = {George Danezis}, + title = {An anomaly-based censorship-detection system for {Tor}}, + institution = {The Tor Project}, + number = {2011-09-001}, + year = {2011}, + month = {September}, + url = {https://research.torproject.org/techreports/detector-2011-09-09.pdf} +} + +@techreport{tor-2011-08-001, + author = {Roger Dingledine}, + title = {Better guard rotation parameters}, + institution = {The Tor Project}, + number = {2011-08-001}, + year = {2011}, + month = {August}, + url = {https://research.torproject.org/techreports/better-guard-rotation-parameters-2011-08-20.pdf} +} + +@techreport{tor-2011-06-001, + author = {Karsten Loesing}, + title = {An Analysis of {Tor} Relay Stability}, + institution = {The Tor Project}, + number = {2011-06-001}, + year = {2011}, + month = {June}, + url = {https://research.torproject.org/techreports/relay-stability-2011-06-30.pdf} +} + +@techreport{tor-2011-05-001, + author = {Roger Dingledine}, + title = {Strategies for getting more bridges}, + institution = {The Tor Project}, + number = {2011-05-001}, + year = {2011}, + month = {May}, + url = {https://research.torproject.org/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf} +} + +@techreport{tor-2011-03-001, + author = {Karsten Loesing}, + title = {Overview of Statistical Data in the {Tor} Network}, + institution = {The Tor Project}, + number = {2011-03-001}, + year = {2011}, + month = {March}, + url = {https://research.torproject.org/techreports/data-2011-03-14.pdf} +} + +@techreport{tor-2011-02-001, + author = {Roger Dingledine}, + title = {Measuring the safety of the {Tor} network}, + institution = {The Tor Project}, + number = {2011-02-001}, + year = {2011}, + month = {February}, + url = {https://research.torproject.org/techreports/measuring-safety-tor-network-2011-02-06.pdf} +} + +@techreport{tor-2010-11-001, + author = {Sebastian Hahn and Karsten Loesing}, + title = {Privacy-preserving Ways to Estimate the Number of {Tor} Users}, + institution = {The Tor Project}, + number = {2010-11-001}, + year = {2010}, + month = {November}, + url = {https://research.torproject.org/techreports/countingusers-2010-11-30.pdf} +} + +@techreport{tor-2010-09-001, + author = {Roger Dingledine}, + title = {Adaptive throttling of {Tor} clients by entry guards}, + institution = {The Tor Project}, + number = {2010-09-001}, + year = {2010}, + month = {September}, + url = {https://research.torproject.org/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf} +} + +@techreport{tor-2009-11-001, + author = {Roger Dingledine and Steven J. Murdoch}, + title = {Performance Improvements on {Tor} or, Why {Tor} is slow and what we're going to do about it}, + institution = {The Tor Project}, + number = {2009-11-001}, + year = {2009}, + month = {November}, + url = {https://research.torproject.org/techreports/performance-2009-11-09.pdf} +} + +@techreport{tor-2009-10-001, + author = {Karsten Loesing}, + title = {Comparison of {GeoIP} Databases for {Tor}}, + institution = {The Tor Project}, + number = {2009-10-001}, + year = {2009}, + month = {October}, + url = {https://research.torproject.org/techreports/geoipdbcomp-2009-10-23.pdf} +} + +@techreport{tor-2009-09-001, + author = {Karsten Loesing}, + title = {Performance of Requests over the {Tor} Network}, + institution = {The Tor Project}, + number = {2009-09-001}, + year = {2009}, + month = {September}, + url = {https://research.torproject.org/techreports/torperf-2009-09-22.pdf} +} + +@techreport{tor-2009-09-002, + author = {Karsten Loesing}, + title = {Reducing the Circuit Window Size in {Tor}}, + institution = {The Tor Project}, + number = {2009-09-002}, + year = {2009}, + month = {September}, + url = {https://research.torproject.org/techreports/circwindow-2009-09-20.pdf} +} + +@techreport{tor-2009-08-001, + author = {Karsten Loesing}, + title = {Analysis of Circuit Queues in {Tor}}, + institution = {The Tor Project}, + number = {2009-08-001}, + year = {2009}, + month = {August}, + url = {https://research.torproject.org/techreports/bufferstats-2009-08-25.pdf} +} + +@techreport{tor-2009-08-002, + author = {Karsten Loesing}, + title = {Measuring the {Tor} Network from Public Directory Information}, + institution = {The Tor Project}, + number = {2009-08-002}, + year = {2009}, + month = {August}, + url = {https://research.torproject.org/techreports/metrics-2009-08-07.pdf} +} + +@techreport{tor-2009-08-003, + author = {Mike Perry}, + title = {{TorFlow}: {Tor} Network Analysis}, + institution = {The Tor Project}, + number = {2009-08-003}, + year = {2009}, + month = {August}, + url = {https://research.torproject.org/techreports/torflow-2009-08-07.pdf} +} + +@techreport{tor-2009-06-002, + author = {Karsten Loesing}, + title = {Measuring the {Tor} Network, Evaluation of Client Requests to the Directories to determine total numbers and countries of users}, + institution = {The Tor Project}, + number = {2009-06-002}, + year = {2009}, + month = {June}, + url = {https://research.torproject.org/techreports/directory-requests-2009-06-25.pdf} +} + +@techreport{tor-2009-06-003, + author = {Karsten Loesing}, + title = {Analysis of Bridge Usage in {Tor}}, + institution = {The Tor Project}, + number = {2009-06-003}, + year = {2009}, + month = {June}, + url = {https://research.torproject.org/techreports/bridges-2009-06-22.pdf} +} + +@techreport{tor-2009-06-001, + author = {Karsten Loesing}, + title = {Measuring the {Tor} Network, Evaluation of Relays from Public Directory Data}, + institution = {The Tor Project}, + number = {2009-06-001}, + year = {2009}, + month = {June}, + url = {https://research.torproject.org/techreports/dirarch-2009-06-22.pdf} +} + +@techreport{tor-2009-04-001, + author = {Sebastian Hahn and Karsten Loesing and Steven J. Murdoch}, + title = {Measuring the {Tor} Network, Simulation of the number of Fast, Stable, and Guard flags for changed requirements}, + institution = {The Tor Project}, + number = {2009-04-001}, + year = {2009}, + month = {April}, + url = {https://research.torproject.org/techreports/flagrequirements-2009-04-11.pdf} +} + +@techreport{tor-2009-02-001, + author = {Roger Dingledine}, + title = {Overhead from directory info: past, present, future}, + institution = {The Tor Project}, + number = {2009-02-001}, + year = {2009}, + month = {February}, + url = {https://research.torproject.org/techreports/overhead-directory-info-2009-02-16.pdf} +} + +@techreport{tor-2008-07-001, + author = {Karsten Loesing and Guido Wirtz}, + title = {Virtual Private Services}, + institution = {The Tor Project}, + number = {2008-07-001}, + year = {2008}, + month = {July}, + url = {https://research.torproject.org/techreports/virtual-private-services-2008-07-25.pdf} +} + +@techreport{tor-2006-11-001, + author = {Roger Dingledine and Nick Mathewson}, + title = {Design of a blocking-resistant anonymity system}, + institution = {The Tor Project}, + number = {2006-11-001}, + year = {2006}, + month = {November}, + url = {https://research.torproject.org/techreports/blocking-2006-11.pdf} +} + +@techreport{tor-2005-02-001, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + title = {Challenges in deploying low-latency anonymity}, + institution = {The Tor Project}, + number = {2005-02-001}, + year = {2005}, + month = {February}, + url = {https://research.torproject.org/techreports/challenges-2005-02.pdf} +} +

1 0

[tech-reports/master] Rename main .tex file to something globally meaningful.
by karsten＠torproject.org 19 Jan '19

19 Jan '19

commit dc4bcb38e7d730ed2c20582fa74c121e7fc9ae31 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 15 16:00:39 2019 +0100 Rename main .tex file to something globally meaningful. --- 2018/sponsor19/report1/.gitignore | 3 +++ 2018/sponsor19/report1/Makefile | 8 ++++---- .../sponsor19/report1/{report1.tex => dos-censorship-report1.tex} | 0 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/2018/sponsor19/report1/.gitignore b/2018/sponsor19/report1/.gitignore new file mode 100644 index 0000000..a9e5fa3 --- /dev/null +++ b/2018/sponsor19/report1/.gitignore @@ -0,0 +1,3 @@ +dos-censorship-report1.pdf +dos-censorship-report1.toc + diff --git a/2018/sponsor19/report1/Makefile b/2018/sponsor19/report1/Makefile index 556c147..66270af 100644 --- a/2018/sponsor19/report1/Makefile +++ b/2018/sponsor19/report1/Makefile @@ -1,7 +1,7 @@ all: - pdflatex report1 - bibtex report1 - pdflatex report1 - pdflatex report1 + pdflatex dos-censorship-report1 + bibtex dos-censorship-report1 + pdflatex dos-censorship-report1 + pdflatex dos-censorship-report1 diff --git a/2018/sponsor19/report1/report1.tex b/2018/sponsor19/report1/dos-censorship-report1.tex similarity index 100% rename from 2018/sponsor19/report1/report1.tex rename to 2018/sponsor19/report1/dos-censorship-report1.tex

1 0

[tech-reports/master] Reformat Sponsor 19 report 1 as Tor tech report.
by karsten＠torproject.org 19 Jan '19

19 Jan '19

commit 430e5d319fc767264031ec41c6c46fd42e0ecc8b Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 15 16:22:43 2019 +0100 Reformat Sponsor 19 report 1 as Tor tech report. --- 2018/sponsor19/report1/dos-censorship-report1.tex | 258 +++------------------- 2018/sponsor19/report1/intro.tex | 4 +- 2018/sponsor19/report1/task10.tex | 14 +- 2018/sponsor19/report1/task10c.tex | 16 +- 2018/sponsor19/report1/task11.tex | 32 +-- 2018/sponsor19/report1/task6.tex | 30 +-- 2018/sponsor19/report1/task7a.tex | 20 +- 2018/sponsor19/report1/task7b.tex | 6 +- 2018/sponsor19/report1/task8.tex | 10 +- 2018/sponsor19/report1/task9.tex | 56 ++--- 2018/sponsor19/report1/tortechrep.cls | 1 + 11 files changed, 125 insertions(+), 322 deletions(-) diff --git a/2018/sponsor19/report1/dos-censorship-report1.tex b/2018/sponsor19/report1/dos-censorship-report1.tex index 8b21a70..e9f09af 100644 --- a/2018/sponsor19/report1/dos-censorship-report1.tex +++ b/2018/sponsor19/report1/dos-censorship-report1.tex @@ -1,20 +1,24 @@ -\documentclass[twoside,openright,11pt]{report} +\documentclass{tortechrep} \newcommand{\todo}[1]{[{\textbf{todo}}: {\em\color{red} #1}]} -\newcommand{\deliverabletitle}{Interim Report 1} -\newcommand{\deliverabletitleshort}{Interim Report 1} -\newcommand{\reportnumber}{1} -\newcommand{\deliverabledate}{November 2018} +\newcommand{\deliverabletitle}{Addressing Denial of Service Attacks on Free and +Open Communication on the Internet} +\newcommand{\deliverablesubtitle}{Interim Report 1} +\newcommand{\reportnumber}{2018-11-001} +\newcommand{\deliverabledate}{November 19, 2018} +\newcommand{\deliverablecontact}{kat(a)torproject.org} +\newcommand{\deliverablefootnote}{This work is licensed under a \href{https://creativecommons.org/licenses/by/4.0/legalcode}{Creative Commons Attribution 4.0 International License}. \ccby} \newcommand{\eg}{\mbox{e.g.}\xspace} \newcommand{\ie}{\mbox{i.e.}\xspace} \newcommand{\deliverableauthorlist}{ -Antonela Debiasi, Roger Dingledine, Arthur Edelstein, Alexander F\ae r\o y, \\ -Matthew Finkel, David Goulet, Kat Hanna, Maggie Haughey, George Kadianakis, \\ -Iain R. Learmonth, Alison Macrina, Maria Xynou } +Antonela Debiasi, Roger Dingledine, Arthur Edelstein,\\% +Alexander F\ae r\o y, Matthew Finkel, David Goulet,\\% +Kat Hanna, Maggie Haughey, George Kadianakis,\\% +Iain R. Learmonth, Alison Macrina, and Maria Xynou}% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -23,31 +27,15 @@ Iain R. Learmonth, Alison Macrina, Maria Xynou } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% Document geometry -% - -% Set up for letter rather than A4 -\usepackage[left=.75in,right=.75in,top=1in,bottom=1in,foot=48pt]{geometry} - -%\setlength{\textheight}{230mm} -%\setlength{\textwidth}{160mm} -%\setlength{\voffset}{-25mm} -%\setlength{\oddsidemargin}{0mm} -%\setlength{\evensidemargin}{0mm} -\addtolength{\parskip}{0.33\baselineskip} - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Package definitions % -\usepackage{helvet} \usepackage{graphicx} \usepackage{subfigure} \usepackage{color} \usepackage{xcolor} \usepackage{chngcntr} \usepackage{longtable} -\usepackage{lastpage} \usepackage{fancyhdr} \usepackage{setspace} \usepackage{url} @@ -61,97 +49,11 @@ Iain R. Learmonth, Alison Macrina, Maria Xynou } \usepackage{ccicons} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% Font definitions -% -\renewcommand\familydefault{\sfdefault} - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Heading style definitions % \setcounter{secnumdepth}{4} -\makeatletter -\renewcommand{\chapter}{\@startsection{chapter}{0}{0mm} - {\baselineskip}% - {\baselineskip}{\clearpage\LARGE\bf\color{black}}} -\renewcommand{\section}{\@startsection{section}{1}{0mm} - {\baselineskip}% - {\baselineskip}{\LARGE\color{black}}}% -\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm} - {\baselineskip}% - {\baselineskip}{\Large\color{black}}}% -\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm} - {\baselineskip}% - {\baselineskip}{\large\color{black}}}% -\makeatother - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% Table of contents styling -% -% Finamore: added dotted lines also for chapters -% solution found at http://tex.stackexchange.com/questions/62438/how-to-add-leaders-to-table-of… -\makeatletter -\renewcommand*\l@chapter[2]{% - \ifnum \c@tocdepth >\m@ne - \addpenalty{-\@highpenalty}% - \vskip 1.0em \@plus\p@ - \setlength\(a)tempdima{1.5em}% - \begingroup - \parindent \z@ \rightskip \@pnumwidth - \parfillskip -\@pnumwidth - \leavevmode %\bfseries - \advance\leftskip\@tempdima - \hskip -\leftskip - #1\nobreak - \xleaders\hbox{$\m@th - \mkern \@dotsep mu\hbox{.}\mkern \@dotsep mu$}\hfill% - \nobreak\hb@xt@\@pnumwidth{\hss #2}\par - \penalty\@highpenalty - \endgroup - \fi} -\renewcommand*\l@section{\@dottedtocline{1}{1.5em}{2.3em}} -\renewcommand*\l@subsection{\@dottedtocline{2}{3.8em}{3.2em}} -\renewcommand*\l@subsubsection{\@dottedtocline{3}{7.0em}{4.1em}} -\renewcommand*\l@paragraph{\@dottedtocline{4}{10em}{5em}} -\renewcommand*\l@subparagraph{\@dottedtocline{5}{12em}{6em}} -\renewcommand*{\@dotsep}{1} -\makeatother - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% Header and footer definitions -% - -%\setlength{\headheight}{52pt} -%\setlength{\footskip}{47pt} -\renewcommand{\headrulewidth}{0pt} -\pagestyle{fancyplain} - -%\fancyhead[L]{\textsf{DoS Resilience \\ D\reportnumber ~\deliverabletitleshort}} -\fancyhead[L]{\textsf{Addressing Denial of Service Attacks on Free and Open Communication on the Internet \\ \deliverabletitleshort}} -\fancyhead[R]{\setlength{\unitlength}{1mm} -\begin{picture}(0,0) - %\put(-70,-4){\includegraphics[width=70mm]{logos/EC-H2020.png}} -\end{picture} -} -\fancyfoot[L]{\setlength{\unitlength}{1mm} -\begin{picture}(0,0) - \put(0,6){\includegraphics[width=10mm]{../torlogo.png}} -\end{picture} -} -\fancyfoot[C]{\vspace{-10mm}\textsf{\thepage\hspace{0.3em}of \pageref{LastPage}}} -\fancyfoot[R]{\vspace{-10mm}\textsf{\deliverabledate}} - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% Miscellaneous document adjustments go here - -% Call the bibliography a references section -\renewcommand*{\bibname}{References} - -% Number figures and tables globally -\counterwithout{figure}{chapter} -\counterwithout{table}{chapter} - %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Define some colors @@ -163,29 +65,6 @@ Iain R. Learmonth, Alison Macrina, Maria Xynou } \definecolor{measurementred}{RGB}{255, 128, 128} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% Define some useful commands - %\EDNOTE{who}{what} - place an editor's note in the document. - %\INNOTE{who}{what} - place an inline note in the document - -\newcommand{\EDNOTE}[2]{ - \par\large\centerline{ - \mbox{ - \begin{tabular}{ll} - \textsf{\textbf{#1}} & - \fbox{ - \begin{minipage}{0.6\linewidth} - \em\color{red} #2 - \end{minipage} - } - \end{tabular} - }} - \par\vspace{4mm} -} - -\newcommand{\INNOTE}[2]{[\textsf{\textbf{#1}}: {\em\color{red} #2}]} - - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \acrodef{AQM}{Active Queue Management} \acrodef{ECN}{Explicit Congestion Notification} @@ -210,151 +89,74 @@ Iain R. Learmonth, Alison Macrina, Maria Xynou } % Front page % \begin{document} -\thispagestyle{empty} -\parindent0pt - -\newcolumntype{R}[1]{>{\raggedleft}p{#1}} -%\begin{tabular}{R{130mm} p{26mm}} -% \vspace{0pt} -% {\bf\small\color{darkgray} H2020 European Union funding \\ for Research \& Innovation} -% {\small\color{darkgray} This project has received funding from the funder \\ -% research and innovation programme under grant agreement No $x$ where $x > 0$.} -% -% & -% \vspace{0pt} -% %\includegraphics[width=26mm]{logos/eu_flag_small.jpg} -%\end{tabular} - -\vspace{20mm} - -\begin{center} -\hspace{-3mm}\includegraphics[width=90mm]{../torlogo.png} -\end{center} - -\vspace{5mm} -\centerline{\rule{0em}{1.5em}\LARGE\bf\color{black}Addressing Denial of Service Attacks on} -\vspace{5mm} -\centerline{\rule{0em}{1.5em}\LARGE\bf\color{black}Free and Open Communication on the Internet} -%\vspace{5mm} -%\centerline{\rule{0em}{1.5em}\bf\Large\color{darkgray}H2020-ICT-688421} - -\vspace{20mm} - -\begin{centering} -\fbox{ - \begin{minipage}{\linewidth} - \vspace*{1mm} - \center - \huge\em\bf\color{darkred}\deliverabletitle - \end{minipage} -} -%\centerline{\huge\em\bf\color{sangria}\deliverabletitle} - -\vspace{2mm} - -\fbox{ - \begin{minipage}{\linewidth} - \large\textsf{ - \begin{tabular}{lll} - \textbf{Authors:} - \deliverableauthorlist - \end{tabular}} - \end{minipage} -} - -\vspace{5mm} - -\mbox{\begin{minipage}{\linewidth} - \textsf{\begin{tabular}{ll} - %\textbf{Report Number:} & D\reportnumber \\ - \textbf{Date of Delivery:} \deliverabledate\\ - \\ - \textbf{Distribution Statement A.} Approved for Public Release, Distribution Unlimited \\ - \\ - This work is licensed under a \href{https://creativecommons.org/licenses/by/4.0/legalcode}{Creative Commons Attribution 4.0 International License}. \ccby - \end{tabular}} - -\end{minipage} -} +\title{\deliverabletitle} +\subtitle{\deliverablesubtitle} -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% Disclaimer -% -%\clearpage -% -% \mbox{\begin{minipage}{\linewidth} -% \addcontentsline{toc}{chapter}{Disclaimer} -% {\LARGE\em\bf\color{black}{Disclaimer}} -% -% \vspace{10mm} -% \em{ -% \todo{I guess we need some disclaimer here related to the funding} -% } -% \end{minipage}} +\author{\deliverableauthorlist} +\contact{\deliverablecontact} +\reportid{\reportnumber\footnote{\deliverablefootnote}} - \end{centering} +\date{\deliverabledate} +\maketitle %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Table of contents % -\clearpage \tableofcontents -\chapter{Introduction} -%\addcontentsline{toc}{chapter}{Introduction} +\section{Introduction} \label{chap:intro} \input{intro.tex} -\chapter{Better Pluggable Transports for Actively Censored Regimes} +\section{Better Pluggable Transports for Actively Censored Regimes} \label{chap:better-pts} -\section{Bridge distribution and pluggable transports} +\subsection{Bridge distribution and pluggable transports} \input{task7a.tex} -\section{Tor Browser and pluggable transports} +\subsection{Tor Browser and pluggable transports} \input{task7b.tex} -\chapter{Beyond Web Browsing} +\section{Beyond Web Browsing} \label{chap:more-apps} \input{task9.tex} -\chapter{Performance Under Resource Constraints} +\section{Performance Under Resource Constraints} \label{chap:perf-bad-networks} \input{task10.tex} \input{task10c.tex} -\chapter{Network and Censorship Measurement} +\section{Network and Censorship Measurement} \label{chap:measurement} \input{task11.tex} -\chapter{Onion Routing Network Defense} +\section{Onion Routing Network Defense} \label{chap:network-defense} \input{task6.tex} -\chapter{A Stronger Research Community} +\section{A Stronger Research Community} \label{chap:stronger-research} \input{task8.tex} -\chapter{Conclusion} +\section{Conclusion} \label{chap:conclusion} \input{conclusion.tex} -\chapter{Acknowledgements} +\section{Acknowledgements} \input{acknowledgements.tex} -\bibliographystyle{plain} \bibliography{../sponsor19,../rfc,../tortechreports,../references} \end{document} diff --git a/2018/sponsor19/report1/intro.tex b/2018/sponsor19/report1/intro.tex index de5a4f9..90d05f4 100644 --- a/2018/sponsor19/report1/intro.tex +++ b/2018/sponsor19/report1/intro.tex @@ -31,7 +31,7 @@ and how we defend against them; and Section~\ref{chap:stronger-research} discusses building a stronger relationship between the Tor Project and academic researchers. -\section{About Tor} +\subsection{About Tor} \label{intro-about-tor} The Tor anonymity system~\cite{tor-design} protects internet users from @@ -69,7 +69,7 @@ privacy. Directory authorities periodically publish a list of the addresses of these available relays, and applications such as Tor Browser choose relays from this list when they connect to the Tor network. -\section{Tor and censorship} +\subsection{Tor and censorship} %\label{intro-tor-censorship} Governments and other censors use a variety of tools to deny people access to diff --git a/2018/sponsor19/report1/task10.tex b/2018/sponsor19/report1/task10.tex index cb05470..0dc5b1d 100644 --- a/2018/sponsor19/report1/task10.tex +++ b/2018/sponsor19/report1/task10.tex @@ -19,7 +19,7 @@ contribute to poor performance for our users. %all parts of the system. % -\section{Performance in resource constrained access networks} +\subsection{Performance in resource constrained access networks} In the more developed world, recent advances in wired broadband networks and cellular networks have led to faster speed when connecting to the internet. But @@ -74,13 +74,13 @@ increase. Until connectivity is completely lost, the Tor protocol and the pluggable transports used with Tor should ideally be able to degrade gracefully by adapting to the changing network conditions. -\section{Improving client performance} +\subsection{Improving client performance} We plan to improve client performance both for users who have bad network connections and also to ensure that performance degrades gracefully when the network is under attack. -\subsection{End-to-end performance} +\subsubsection{End-to-end performance} Network characteristics such as latency, bandwidth, data packet loss, and jitter are highly interrelated. For example, in TCP connections such as those @@ -96,7 +96,7 @@ data must be queued before it can be sent, and this can increase the latency in the network. These locations include network hardware, operating system interfaces and the Tor software. -\subsubsection{Congestion control} +\paragraph{Congestion control} %In looking to reduce the delays introduced by uncontrolled congestion in Tor, %researchers have explored alternative classes of congestion and flow control. @@ -132,7 +132,7 @@ results show that there is clearly room for improvement, although further research is needed before we decide what to implement. -\subsubsection{Improved socket management} +\paragraph{Improved socket management} Congestion does not only occur within Tor relay software or within the networks that join them together; it can also occur in the operating system that the Tor @@ -157,7 +157,7 @@ network throughput by nearly 10\% in experiments. This improved algorithm has been included in the Tor relay software since version 0.3.2. -\subsection{Resumable uploads} +\subsubsection{Resumable uploads} Some users may have access networks that provide intermittent connectivity. This can occur even with good infrastructure when, for example, a user switches @@ -178,7 +178,7 @@ could be added to Tor Browser to assist in resuming large uploads or downloads in the event that connectivity is interrupted. If transfers resume automatically this may even be transparent to the user. -\subsection{Striping connections} +\subsubsection{Striping connections} Bridges providing access to the Tor network via pluggable transports often have lower bandwidth available than regular relays. To help in load-balancing across diff --git a/2018/sponsor19/report1/task10c.tex b/2018/sponsor19/report1/task10c.tex index c1d8cf8..4dc41e8 100644 --- a/2018/sponsor19/report1/task10c.tex +++ b/2018/sponsor19/report1/task10c.tex @@ -1,4 +1,4 @@ -\section{Performance while under attack} +\subsection{Performance while under attack} \label{perf-dos-attacks} There are several ways to mount a Denial of Service (DoS) attack against the @@ -10,9 +10,9 @@ The following is heavily inspired by the 2015 Tor technical report defenses''~\cite{dos-techreport}. Section~\ref{dos} describes some recent attacks on the Tor network. -\subsection{Types of DoS attacks} +\subsubsection{Types of DoS attacks} -\subsubsection{CPU consumption} +\paragraph{CPU consumption} Most of Tor's running time is spent performing expensive cryptographic computation. It requires a lot of processing power on the CPU (central @@ -34,7 +34,7 @@ other things, it could render Tor unable to accomplish its real tasks. processor use. \end{itemize} -\subsubsection{Memory consumption} +\paragraph{Memory consumption} Tor relies on having adequate computer memory available to function well. Exhausting the available memory on a server running a relay leads to @@ -45,7 +45,7 @@ many places in the Tor code that could benefit from memory optimization: using smaller objects in memory, cleaning up more frequently, optimizing access to shared or common data, and so on. -\subsubsection{Disk space consumption} +\paragraph{Disk space consumption} These days, we rarely see servers\textemdash or even clients\textemdash with very low disk space, but disk space is still very @@ -57,7 +57,7 @@ create the Tor consensus. not be the cause of available disk space becoming low, but it is important that we ensure that Tor can keep running, even with no available space at all. -\subsubsection{Bandwidth consumption} +\paragraph{Bandwidth consumption} Attacks that disrupt Tor's ability to move data between the client, the relays in a circuit, and a destination by consuming a lot of bandwidth are @@ -98,7 +98,7 @@ These are rare, but high-impact~\cite{jansen2014sniper}. \end{itemize} -\subsubsection{Network resources exhaustion} +\paragraph{Network resources exhaustion} TCP connections are specified with a port and IP address. There are 65535 available ports. If an attacker opens, and keeps open, connections to most or @@ -113,7 +113,7 @@ We could also explore using UDP, another transport protocol that doesn't suffer It might also be possible to use IPv6, which has a much larger range of addresses, to mitigate this problem. -\subsection{Future directions} +\subsubsection{Future directions} To improve Tor's resilience against Denial of Service attacks, we should favor defenses that address multiple types of attacks simultaneously over defenses diff --git a/2018/sponsor19/report1/task11.tex b/2018/sponsor19/report1/task11.tex index 9f2e04c..bac2d73 100644 --- a/2018/sponsor19/report1/task11.tex +++ b/2018/sponsor19/report1/task11.tex @@ -8,7 +8,7 @@ team collects about Tor users and the Tor network; Section~\ref{censorship-of-tor} describes information that the Open Observatory of Network Interference (OONI)~\cite{ooni-paper} and the Tor Networks team collect about censorship of the Tor network. -\section{Tor Metrics public datasets} +\subsection{Tor Metrics public datasets} \label{sec:public-datasets} Tor Metrics \cite{wecsr10measuring-tor} archives historical data about the Tor @@ -34,7 +34,7 @@ contains a number of customizable plots to show user, traffic, relay, bridge, and application download statistics over a requested time period for a particular country. -\subsection{Relay and bridge user counts} +\subsubsection{Relay and bridge user counts} The number of Tor users is one of our most important statistics. It is vital to know how many people use the Tor network on a daily basis, whether @@ -58,7 +58,7 @@ Relay users are users that connect directly to a relay in order to connect to the Tor network; bridge users connect to a bridge as an entry point into the Tor network. -\subsection{Safe counting and PrivCount} +\subsubsection{Safe counting and PrivCount} Recent advances in privacy-preserving metrics collection such as private set-union cardinality~\cite{psc-ccs2017} and PrivCount~\cite{privcount-ccs2016} @@ -86,7 +86,7 @@ early count of two million daily users. We need to closely examine the methodologies used in this work to validate its findings. -\subsection{Reliable geolocation} +\subsubsection{Reliable geolocation} In producing metrics relating to countries, for example the top countries by daily users shown in Table~\ref{tbl:top-user-countries}, Tor Metrics @@ -159,7 +159,7 @@ not possible to say whether a switch would improve this situation or not. We hope to analyze the different databases and feeds available to us to determine which options best fit our requirements. -\subsection{Network performance} +\subsubsection{Network performance} \label{sec:onionperf} The performance that Tor users experience depends on many factors and is @@ -229,7 +229,7 @@ access networks. Further, to understand the performance for users in denied countries, performance measurements should be carried out using pluggable transports. -\section{Detecting censorship of Tor} +\subsection{Detecting censorship of Tor} \label{censorship-of-tor} The Tor network offers online anonymity, privacy, and censorship circumvention. @@ -254,7 +254,7 @@ In recent years, however, we have (mainly) observed the blocking of the Tor network in the following countries: Egypt, Ethiopia, China, Iran, Turkey, and Venezuela. -\subsection{Open Observatory of Network Interference} +\subsubsection{Open Observatory of Network Interference} \label{ooni} Over the last several years, we have been monitoring the blocking of the Tor @@ -294,7 +294,7 @@ where Tor is blocked, such as Egypt and Iran. We will continue to expand our community engagement activities to monitor the blocking of Tor and to make it more resilient to censorship. -\subsubsection{Egypt} +\paragraph{Egypt} Following the blocking of hundreds of media websites~\cite{ooni-egypt-summary}, @@ -343,7 +343,7 @@ OONI Probe in Egypt between June and November 2017.} Recent OONI measurements suggest that access to the Tor network, when not using a private obfs4 bridge, remains blocked in Egypt. -\subsubsection{Ethiopia} +\paragraph{Ethiopia} During a wave of protests in 2016~\cite{bbc-ethiopia-protests}, numerous @@ -381,7 +381,7 @@ most recent measurements suggest that access to the Tor network remains blocked as well. Bridge reachability tests have never been run in Ethiopia, and so it remains unclear if access to Tor bridges is blocked. -\subsubsection{China} +\paragraph{China} China is known for its pervasive internet censorship apparatus, which also involves the blocking of numerous circumvention tools. Most OONI @@ -438,7 +438,7 @@ the China Education \& Research Network Center (AS 4538). Bridge reachability tests haven't been run in China in recent years, limiting our ability to evaluate whether they work locally or not. -\subsubsection{Iran} +\paragraph{Iran} The breadth and depth of internet censorship in Iran is pervasive. Thousands of OONI Probe @@ -462,7 +462,7 @@ deterministic, as we've observed the dynamic blocking and unblocking of services over time. Censorship measurement is therefore required on an ongoing basis. -\subsubsection{Turkey} +\paragraph{Turkey} Direct connections to the Tor network appear to be blocked in Turkey as well. Between June 2017 and @@ -487,7 +487,7 @@ the Tor network. This ISP also appears to be blocking access to Tor's website, b Vodafone (AS 15897). Bridge reachability tests have never been run by volunteers in Turkey, limiting our ability to assess whether Tor bridges work locally. -\subsubsection{Venezuela} +\paragraph{Venezuela} A few months ago, one ISP in Venezuela blocked access to the Tor network as well. @@ -540,7 +540,7 @@ The Tor Project website has remained accessible in CANTV (and other networks) all along, even during the time that direct Tor network connections and default obfs4 bridges were blocked. -\subsection{Tor Metrics anomaly detection} +\subsubsection{Tor Metrics anomaly detection} Tor Metrics has an ``early warning system"~\cite{tor-2011-09-001} to indicate anomalies in the counts of directly connecting Tor users. The detector is based @@ -583,7 +583,7 @@ and reports daily to a mailing list~\cite{infolabe} but is not yet integrated with Tor Metrics. -\subsection{Events timeline} +\subsubsection{Events timeline} Tor Metrics maintains a timeline~\cite{tor-metrics-news} of events @@ -622,7 +622,7 @@ context when interpreting the user count data and visualizations.} \label{tbl:timeline-examples} \end{table} -\subsection{Future directions} +\subsubsection{Future directions} There is significant work to be done to get us from knowing when access to the Tor network is blocked, to knowing which pluggable transports work in which diff --git a/2018/sponsor19/report1/task6.tex b/2018/sponsor19/report1/task6.tex index c9c6aed..4c28acb 100644 --- a/2018/sponsor19/report1/task6.tex +++ b/2018/sponsor19/report1/task6.tex @@ -1,4 +1,4 @@ -\section{Tor network health} +\subsection{Tor network health} \label{sec:network-health} The health of the Tor network is crucial to all of the services Tor provides, @@ -11,10 +11,10 @@ Section~\ref{health-bad} describes our ongoing fight against malicious relays and includes our detection methods and our process to remove a relay from the network. -\subsection{The state of the network} +\subsubsection{The state of the network} \label{health-state} -\subsubsection{Numbers} +\paragraph{Numbers} The Tor network is currently composed of about 6400 relays run by volunteers around the world. As Figure~\ref{png-network} shows, the @@ -93,7 +93,7 @@ numbers come from the number of directory requests reported by bridges.} \end{figure} -\subsubsection{Diversity} +\paragraph{Diversity} Diversity is an important factor for the safety and anonymity provided by the Tor network. We can measure diversity in a variety of ways, but for this @@ -157,12 +157,12 @@ advocate who helps support current relay operators and does outreach to attract new ones. In addition, as part of our global south initiative, our community liaison has been helping volunteers set up relays in those regions. -\subsection{Malicious relays}\label{health-bad} +\subsubsection{Malicious relays}\label{health-bad} This section describes the types of malicious relays we see in the network and how we deal with them. -\subsubsection{Rejecting relays} +\paragraph{Rejecting relays} Anyone on the Internet can run a relay which means that we need to be aware that malicious actors can join anonymously and disrupt the network---sometimes @@ -196,7 +196,7 @@ would have funding to hire a \emph{network health engineer} to monitor the network more closely and improve our detection methods. -\subsubsection{Malicious onion service directories} +\paragraph{Malicious onion service directories} A relay that has been online for 96 hours or more can become an \emph{onion @@ -215,7 +215,7 @@ For this reason, we have a scanner that detects onion service directories that collect .onion addresses and visit them. Every week we reject 5 to 10 relays from the network that are doing this. -\subsection{Current outlook and future directions} +\subsubsection{Current outlook and future directions} The Tor network is healthy in terms of capacity. % It is not currently using all @@ -244,14 +244,14 @@ more OS diversity to the network. Improving our network monitoring is an ongoing goal. The health of the network really depends on collaboration among everyone in our community. -\section{Denial of service} +\subsection{Denial of service} \label{dos} This section describes the denial of service attacks that the Tor network faces. We'll use a recent example to demonstrate how important it is that our community and monitoring work together. -\subsection{Notable attacks} +\subsubsection{Notable attacks} \label{dos-attacks} In 2015, Nick Mathewson, Tor maintainer, released a technical report @@ -262,7 +262,7 @@ Over the years, the Tor Project and community have dealt with many attacks of this kind, and they usually come as a surprise. This section highlights some of the attacks we have faced and the lessons they have taught us. -\subsubsection{Sefnit botnet} +\paragraph{Sefnit botnet} On the 20th of August 2013, the number of users connected to the network rose to abnormal levels~\cite{botnet-2013} (see Figure~\ref{dos-sefnit}). @@ -290,7 +290,7 @@ Fortunately, by the end of 2013, the rise in users was identified by a Microsoft researcher as part of the Sefnit botnet. It was removed by Microsoft anti-virus at that point. -\subsubsection{The sniper attack} +\paragraph{The sniper attack} In February 2014, a paper was presented at the Network and Distributed Systems Security symposium titled \textbf{The Sniper Attack: Anonymously @@ -308,7 +308,7 @@ don't know what its actual effects might be. The sniper attack showed us that taking down a relay could lead to deanonymizing specific onion services. -\subsubsection{DoS attack using onion services} +\paragraph{DoS attack using onion services} In mid December 2017, relay operators started to report to the tor-relays mailing list that they were seeing spikes in traffic to their relays and @@ -392,7 +392,7 @@ of the network recovered quickly. After a few months, the attack stopped. To this day, these defenses are still in place, protecting the Tor network from such abuse. -\subsubsection{Key takeaways} +\paragraph{Key takeaways} These episodes took us by surprise and forced some Tor developers to drop everything to investigate and work on defenses. But they produced some key @@ -420,7 +420,7 @@ takeaways. quickly spiral out of control and we take them extremely seriously. \end{itemize} -\subsection{The future} \label{dos-future} +\subsubsection{The future} \label{dos-future} There are several important points to keep in mind when we consider how to defend against future DoS attacks on the Tor network. diff --git a/2018/sponsor19/report1/task7a.tex b/2018/sponsor19/report1/task7a.tex index 7e78c5b..4617e25 100644 --- a/2018/sponsor19/report1/task7a.tex +++ b/2018/sponsor19/report1/task7a.tex @@ -25,7 +25,7 @@ video streaming, or Tor. Pluggable transports try to solve this problem by disguising the Tor traffic between the user and the bridge so that it doesn't look like Tor traffic. -\subsection{Bridge distribution} +\subsubsection{Bridge distribution} \label{bridge-distrib} Because bridge addresses are not listed in the public directory of relays, @@ -62,7 +62,7 @@ Tor Browser 8.0, released in September of 2018, includes the ability to request bridge addresses from within the application. More information about the way Tor Browser helps get around censorship is in Section~\ref{browser-censorship}. -\subsection{Pluggable transports} +\subsubsection{Pluggable transports} \label{pt-types} A pluggable transport is a program that is used between the @@ -90,7 +90,7 @@ Go language very popular for developing pluggable transports~\cite{goptlib}. The following sections describe some pluggable transports that either have been used by Tor, or that have the potential be used by Tor in the future. -\subsubsection{Obfsproxy} +\paragraph{Obfsproxy} Obfsproxy makes Tor traffic look like a random stream of bytes. This type of pluggable transport is known as a \emph{look-like-nothing} pluggable transport @@ -126,14 +126,14 @@ bridge replies. This means obfs4 can resist active probing attacks. Obfs4 is one of the most popular pluggable transports in use today. -\subsubsection{ScrambleSuit} +\paragraph{ScrambleSuit} ScrambleSuit, like obfsproxy, is a pluggable transport that makes traffic look like a random stream of bytes. But ScrambleSuit also changes the lengths of its data packets, as well as the time between sending them, to confuse censors that rely on those characteristics to recognize Tor traffic. -\subsubsection{FTE} +\paragraph{FTE} Format Transforming Encryption (FTE) was one of the first pluggable transports that did not belong in the look-like-nothing group. Instead, FTE uses an @@ -145,7 +145,7 @@ This type of pluggable transport is useful in the face of a ``whitelisting'' censor, that is, a censor that has a list of protocols that it recognizes and allows. -\subsubsection{Flashproxy} +\paragraph{Flashproxy} Flashproxy~\cite{flashproxy-pets12} is a pluggable transport that allows censored users to quickly find and use short-lived proxies operated by @@ -167,7 +167,7 @@ reachable on the internet drastically reduces the usefulness of the design. See Section~\ref{pt:snowflake} for a description of Snowflake, an improved version of Flashproxy that solves this problem. -\subsubsection{Meek} +\paragraph{Meek} Meek~\cite{meek} is a pluggable transport that uses \emph{domain fronting}~\cite{domain-fronting} to get around @@ -188,7 +188,7 @@ deployed is the Microsoft Azure cloud. So far, meek has proven resilient to blocking. -\subsubsection{Marionette} +\paragraph{Marionette} Marionette is a fairly new pluggable transport developed by the US company RedJack. Marionette's design~\cite{marionette} is similar to that of @@ -204,7 +204,7 @@ Marionette is in the late development stage. The next step is to deploy it to a set of stable bridges so that we can evaluate it in a variety of censored locations. -\subsubsection{Next generation pluggable transport: Snowflake} +\paragraph{Next generation pluggable transport: Snowflake} \label{pt:snowflake} The most promising next generation pluggable transport is @@ -237,7 +237,7 @@ The Tor Project is in the process of hiring a software developer to explore some of these questions and to work on other anti-censorship technologies as well. -\subsection{Designing new pluggable transports} +\subsubsection{Designing new pluggable transports} \label{pt:design} A common anti-censorship strategy is to make it unappealing for censors to diff --git a/2018/sponsor19/report1/task7b.tex b/2018/sponsor19/report1/task7b.tex index b277953..923c456 100644 --- a/2018/sponsor19/report1/task7b.tex +++ b/2018/sponsor19/report1/task7b.tex @@ -1,4 +1,4 @@ -\subsection{Tor Browser} +\subsubsection{Tor Browser} \label{browser-censorship} In many places in the world, censorship of the web is common. Users are @@ -72,7 +72,7 @@ it is safe, for example, to be logged into Facebook in one tab and to post anonymously to a blog in another tab. This is a Tor feature that Mozilla has also implemented in Firefox. -\subsubsection{Usability testing and global outreach} +\paragraph{Usability testing and global outreach} \label{ux-testing-outreach} To make useful software, especially software that aims to keep people safe, it @@ -165,7 +165,7 @@ network. \label{new-circuit-display} \end{figure} -\subsection{Tor Browser for Android} +\subsubsection{Tor Browser for Android} \label{tb-android} Historically, Tor Browser has only been developed for desktop computers running diff --git a/2018/sponsor19/report1/task8.tex b/2018/sponsor19/report1/task8.tex index 09d44bb..d9f11cb 100644 --- a/2018/sponsor19/report1/task8.tex +++ b/2018/sponsor19/report1/task8.tex @@ -1,5 +1,5 @@ -\section{Tor's role in the research community} +\subsection{Tor's role in the research community} Just about every major computer security conference these days has a paper analyzing, attacking, or improving Tor. While fifteen years ago the field of @@ -54,7 +54,7 @@ who write their theses on Tor. The original Tor design paper from 2004 now has over 4000 citations, and in 2014 Usenix picked that paper out of all the security papers published in 2004 to win their Test of Time award. -\subsection{Tor research resources} +\subsubsection{Tor research resources} Resources for researchers are collected within the Tor Research Portal~\cite{research-portal} which is currently undergoing a redesign. This @@ -70,7 +70,7 @@ Figure~\ref{fig:research-portal-mock}. \label{fig:research-portal-mock} \end{figure} -\subsubsection{Datasets} +\paragraph{Datasets} We've been collecting data to learn more about the Tor network: how many relays and clients there are in the network, what capabilities they have, how fast the @@ -79,7 +79,7 @@ network, etc. We are also developing tools to process these huge data archives and come up with useful statistics. These datasets are described in more detail in Section~\ref{sec:public-datasets}. -\subsubsection{Measurement and attack tools} +\paragraph{Measurement and attack tools} We're building a collection of tools that can be used to measure, analyze, or perform attacks on Tor. Many research groups need to do similar @@ -97,7 +97,7 @@ wrong is important, and we recognize that the incentives in academia aren't aligned with spending energy on designing defenses, but it sure would be great to get more people working on how to address the attacks. -\subsection{Tor research safety board} +\subsubsection{Tor research safety board} The research safety board is a group of researchers who study Tor, and who want to \emph{minimize privacy risks while fostering a better diff --git a/2018/sponsor19/report1/task9.tex b/2018/sponsor19/report1/task9.tex index e0472e7..e209957 100644 --- a/2018/sponsor19/report1/task9.tex +++ b/2018/sponsor19/report1/task9.tex @@ -6,7 +6,7 @@ applications like web browsing, we would like to explore secure messaging and other asynchronous applications. We want to consider more use cases than just web browsing. -\section{Existing apps that use Tor} +\subsection{Existing apps that use Tor} \label{apps-that-use-tor} As a first step, we would like to understand whether existing prototypes @@ -15,17 +15,17 @@ These tools include messaging and email apps, secure operating systems, tools that send traffic from existing apps over the Tor network, monitoring tools, and file sharing apps. -\subsection{Web browsers} +\subsubsection{Web browsers} In addition to Tor Browser, there are a number of web browsers that use the Tor network and protect users' privacy to varying degrees. These include OnionBrowser~\cite{onion-browser}, Brave~\cite{brave}, and Cliqz\cite{cliqz}. -\subsection{Using mobile apps with the Tor network} +\subsubsection{Using mobile apps with the Tor network} The following apps send their internet traffic over the Tor network, whether by using Tor's proxy interface, as Orbot does, or by providing a ``system-wide VPN'' interface as iCepa does. -\subsubsection{Orbot} +\paragraph{Orbot} Orbot~\cite{orbot} is an open-source app that allows other apps to send their internet traffic through it and then through the Tor network, thereby hiding @@ -35,25 +35,25 @@ as it does not provide any additional anti-tracking measures -- it is trivial for apps or websites to track users in most web browsers and many other apps even if the IP address is hidden. -\subsubsection{iCepa} +\paragraph{iCepa} iCepa~\cite{icepa} is a new experimental app for connecting iOS apps to the Tor network. iCepa is in alpha. -\subsection{Communications} +\subsubsection{Communications} From peer to peer messaging apps, to email clients, there are a number of different applications that people can use to anonymize their communications: -\subsubsection{Briar} +\paragraph{Briar} Briar~\cite{briar} is an open source peer-to-peer messaging app for Android. Briar sends its messages through the Tor network, preventing third parties from observing which parties are communicating with each other or revealing their IP addresses. -\subsubsection{Ricochet} +\paragraph{Ricochet} Ricochet~\cite{ricochet} is a desktop app that offers peer-to-peer messaging, without exposing information about who is communicating. All messages are sent @@ -61,12 +61,12 @@ wholly inside the Tor network. Ricochet uses Tor onion services to connect users to one another, eliminating the central server that most messaging apps use. -\subsubsection{ChatSecure} +\paragraph{ChatSecure} ChatSecure~\cite{chatsecure} is an open source iOS app offering optional Tor support that hides the device's IP address and allows messages to bypass restrictive firewalls. -\subsubsection{TorBirdy} +\paragraph{TorBirdy} TorBirdy~\cite{tor-birdy} is an extension for Thunderbird, a desktop email client, that is developed and maintained by members of the Tor Project. @@ -74,14 +74,14 @@ TorBirdy sends email from Thunderbird over the Tor network. This means that the email servers a message passes through do not learn the user's IP address. It also hides email metadata to protect users' privacy. TorBirdy is in beta. -\subsection{Secure operating systems} +\subsubsection{Secure operating systems} Currently there are a number of Linux-based operating systems which aim to provide anonymity and privacy to their users. These OSes send their internet traffic through the Tor network. These include Tails (The Amnesic Incognito Live System)~\cite{tails}, Whonix~\cite{whonix}, and Qubes~\cite{qubes}. -\subsection{Monitoring tools} +\subsubsection{Monitoring tools} -\subsubsection{OONI Probe} +\paragraph{OONI Probe} OONI Probe~\cite{ooni-probe} is an app that runs on Mac OS X, Linux, Android, and iOS that allows users to run tests to determine if their internet @@ -89,7 +89,7 @@ connection is being censored or otherwise experiencing interference. OONI is a Tor project that monitors and reports on censorship around the world. See Section~\ref{ooni} for more information. -\subsubsection{Haven} +\paragraph{Haven} Haven~\cite{haven} is an Android app that uses device sensors to monitor a physical space. It detects motion, sound, vibration and light, and watches for unexpected guests and intruders. It offers a Tor onion service feature that @@ -97,18 +97,18 @@ allows the operator to connect to the device remotely and view its event logs and captured media. Haven is currently in beta. -\subsection{File sharing} +\subsubsection{File sharing} There are a few applications currently available which allow anonymous file sharing over the Tor network: -\subsubsection{OnionShare} +\paragraph{OnionShare} OnionShare~\cite{onionshare} is a desktop app that allows users to send files to one another over the Tor network. This prevents observers from seeing who is sending and receiving the files. -\subsubsection{GlobaLeaks} +\paragraph{GlobaLeaks} GlobaLeaks~\cite{globaleaks} is software that enables people and organizations to set up their own secure, anonymous whistleblower platforms. When a user @@ -120,7 +120,7 @@ There are a wide variety of GlobaLeaks deployments around the world for purposes such as investigative journalism, anti-corruption activism, transparency activism, and anti-crime activism. -\subsubsection{SecureDrop} +\paragraph{SecureDrop} SecureDrop~\cite{securedrop} is server software that allows whistleblowers to send files anonymously and securely to journalists. It functions as a Tor onion @@ -129,7 +129,7 @@ Over the past few years, it has become very common for major news organizations to deploy SecureDrop. The New York Times, The Associated Press, The Guardian, and ProPublica are just a few of the organizations that use SecureDrop. -\subsubsection{OpenArchive} +\paragraph{OpenArchive} OpenArchive is a new app for Android for uploading and sharing media, including video. It sends its traffic over the Tor network to the Internet Archive and @@ -137,7 +137,7 @@ other archives. OpenArchive looks promising, but we need to examine whether Open Archive solves the problems that actual users have and assess its usability at accomplishing these goals. -\section{Applications for users under censorship} +\subsection{Applications for users under censorship} We conducted a survey of the landscape of apps popular among users behind censorship, and thought about how we can serve those users, considering both @@ -271,14 +271,14 @@ work with Tor for users in China?'' %\end{itemize} % % -%\subsection{TenCent apps and services} +%\subsubsection{TenCent apps and services} % -%\subsubsection{WeChat} +%\paragraph{WeChat} % %"Weixin/WeChat reached more than 938 million monthly active user accounts as of %the first quarter of 2017."~\cite{tencent-social} % -%\subsubsection{QQ} +%\paragraph{QQ} % %QQ is an instant messaging app potentially aimed at younger users, complete %with comics, games, and a payment service built in. @@ -287,7 +287,7 @@ work with Tor for users in China?'' %accounts and more than 266 million people were using QQ %simultaneously."~\cite{tencent-social} % -%\subsubsection{QZone} +%\paragraph{QZone} % %Qzone is a social media platform. It allows image and video upload, live %streaming, games, blog posts, etc. Might be an important focus later on, given @@ -297,21 +297,21 @@ work with Tor for users in China?'' %of 2 trillion photos.As of the first quarter of 2017, Qzone had 632 million %monthly active user accounts."~\cite{tencent-social}. % -%\subsubsection{China Reading Limited (Tencent Literature)} +%\paragraph{China Reading Limited (Tencent Literature)} % %"China Reading Limited brings the full integration of online and traditional %literary works to one platform."\cite{tencent-social} % -%\subsubsection{QQ Music} +%\paragraph{QQ Music} % %QQ Music is a music streaming service.\cite{tencent-social} % -%\subsubsection{Penguin e-sports} +%\paragraph{Penguin e-sports} % %Penguin e-sports is a mobile live-streaming service for e-sports, similar to %Twitch.\cite{tencent-social} % -%\subsubsection{NOW Live} +%\paragraph{NOW Live} % %NOW Live is a video live-streaming platform.\cite{tencent-social} % diff --git a/2018/sponsor19/report1/tortechrep.cls b/2018/sponsor19/report1/tortechrep.cls new file mode 120000 index 0000000..ce75af9 --- /dev/null +++ b/2018/sponsor19/report1/tortechrep.cls @@ -0,0 +1 @@ +../../../tortechrep.cls \ No newline at end of file

1 0

[translation/tpo-web] Update translations for tpo-web
by translation＠torproject.org 19 Jan '19

19 Jan '19

commit 7f9e4d85d59bca05d693b3ff819519135953f068 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Jan 19 08:19:14 2019 +0000 Update translations for tpo-web --- contents+es.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contents+es.po b/contents+es.po index 684d9fb9f..1c26523f5 100644 --- a/contents+es.po +++ b/contents+es.po @@ -1936,7 +1936,7 @@ msgstr "" #: templates/footer.html:19 msgid "Our mission:" -msgstr "Nuestra misión" +msgstr "Nuestra misión:" #: templates/footer.html:19 msgid ""

1 0

[translation/tpo-web] Update translations for tpo-web
by translation＠torproject.org 19 Jan '19

19 Jan '19

commit 05074b796b1ede03754dfd6df4221778c7781f3a Author: Translation commit bot <translation(a)torproject.org> Date: Sat Jan 19 07:19:22 2019 +0000 Update translations for tpo-web --- contents+es.po | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/contents+es.po b/contents+es.po index 06e5d36c8..684d9fb9f 100644 --- a/contents+es.po +++ b/contents+es.po @@ -112,11 +112,11 @@ msgstr "Prensa" #: https//torproject.org/menu/ (content/menu/contents+en.lrpage.body) msgid "Blog" -msgstr "" +msgstr "Blog" #: https//torproject.org/menu/ (content/menu/contents+en.lrpage.body) msgid "Newsletter" -msgstr "" +msgstr "Gacetilla" #: https//torproject.org/menu/ (content/menu/contents+en.lrpage.body) msgid "Contact" @@ -1862,7 +1862,7 @@ msgstr "" #: https//torproject.org/about/sponsors/torfox/ #: (content/about/sponsors/torfox/contents+en.lrsponsor.name) msgid "Torfox" -msgstr "" +msgstr "Torfox" #: https//torproject.org/about/sponsors/USSD-DHRL/ #: (content/about/sponsors/USSD-DHRL/contents+en.lrsponsor.name) @@ -1890,7 +1890,7 @@ msgstr "" #: templates/about.html:7 templates/homepage.html:8 templates/layout.html:7 msgid "Tor Project" -msgstr "Proyecto Tor" +msgstr "Tor Project" #: templates/download.html:7 msgid "Get connected" @@ -1936,7 +1936,7 @@ msgstr "" #: templates/footer.html:19 msgid "Our mission:" -msgstr "Nuestra misión:" +msgstr "Nuestra misión" #: templates/footer.html:19 msgid "" @@ -1964,7 +1964,7 @@ msgid "" "found in our " msgstr "" "Se pueden encontrar, la marca registrada, las notas de derechos de autor, y " -"las reglas de uso por terceras partes, en nuestra " +"las reglas de uso por terceras partes, en nuestra" #: templates/hero-home.html:2 msgid "Browse Privately." @@ -2024,7 +2024,7 @@ msgstr "" #: templates/home.html:63 msgid "Learn more" -msgstr "" +msgstr "Leer más" #: templates/home.html:81 msgid "BROWSE FREELY"

1 0

[tpo/staging] typo
by emmapeel＠torproject.org 19 Jan '19

19 Jan '19

commit b318b4f6d013f3add8848aa10519ae6b55513c58 Author: emma peel <emma.peel(a)riseup.net> Date: Sat Jan 19 07:46:03 2019 +0100 typo --- content/about/sponsors/mdf/contents.lr | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/about/sponsors/mdf/contents.lr b/content/about/sponsors/mdf/contents.lr index 4eced17..b661c2f 100644 --- a/content/about/sponsors/mdf/contents.lr +++ b/content/about/sponsors/mdf/contents.lr @@ -4,7 +4,7 @@ active: True --- time: 2016 - 2018 --- -name: Media Democracy Found +name: Media Democracy Fund --- logo: /static/images/sponsors/mdf.png ---

1 0

Jump to page: